[GAME] EmptyEpsilon

13435363739

Comments

  • Hi!

    I am trying to build from the source for Windows using Cmake, but the instructions aren't finalized and I can't get it working.
    I also followed the instructions for CodeBlocks and MinGW, but that failed also.
    I am able to build from the source for Linux without any problems though.

    Does anyone have instructions for building from the source which would work for Windows?
  • If you can build with a linux machine, you can also build the windows version with a linux machine. You need the mingw-w64 cross compiler package for that.

    I'll see if I can back-port the SP2 build system to EE1, it's much smarter and better setup. On linux, I can build a Win32 package for anything build with SP2 on a clean debian setup with just a few minor steps. Unlike the EE1 build that requires manually building a bunch of libraries first.
  • New windows build is available at:
    http://daid.github.io/EmptyEpsilon/#tabs=5

    Also, the Android build is now supplied by my CI system when I push a build, so that is available at:
    https://github.com/daid/EmptyEpsilon/releases/tag/EE-2019.09.09

    At some point, this will match a single download location again.
  • Awesome, thanks daid!
  • edited September 2019
    Now the windows version crashes with a bunch of dll not found errors (seems to be the same that were "too many" while building previously here)
    I just tried to build from the release source, and it still builds a running exe here.
    So maybe there is some version mismatch going on?
  • edited September 2019
    Ah, shiet, yes. My local release build is using a different version of SFML then the new build scripts. That's causing the dll mismatch problems.

    I didn't want to use the new build system yet, as that does not include the crash logger...
  • I just copied all the old .dlls and it worked reasonably well for some test games.
  • New attempt. Note that I've moved the file hosting to github releases. Downloads are still available from:
    http://daid.github.io/EmptyEpsilon/#tabs=5
    But now hosted at:
    https://github.com/daid/EmptyEpsilon/releases
  • @daid - sorry for the hassles, but it's still throwing an error at start.

    "The procedure entry point dbgcore.MiniDumpReadDumpStream could not be located in the dynamic link library dbghelp.dll"

    Just in case, I did try both Win releases and got same result.
  • The main website points to the downloads of the github releases, so they are the same file. No need to try both.

    Seems to be something related to the crash logger. I'll have a look, but I might just disable the crash logger for now. To we have a release that works.
  • It starts fine on my work laptop. So there must be a stray dll on your system that is causing the issue. Check if you have a dbghelp.dll installed somewhere in windows/system32 or something.
  • yes, there is such a critter lurking in the bowls of the windows files; however, ver 05.21 starts just fine and doesn't complain about the dll. I did a fresh reboot prior to testing again.

    Is anyone else having this problem?
  • I conferred with @BlueShadow and he suggested renaming the dbghelp.dll file in the EE directory (temp .keep name of course), and that did allow EE to start! Excellent.

    I did do a quick round of tests, and threw a gazillion drones together in a mass conflagration test, and the engine ran solid, no crashes, and seemed to handle it quite well. Most excellent! Thanks so very much @daid! I'll do some more tests of course, but at least for now it appears that it's fully 'game on!' for our drones in CtF scenarios. The Scouts are going to go ape over this! Thank you again.

    Now, ref the dbghelp.dll issue, does this seem to be perhaps an incompatibility with something else I've installed on my machine or would it be with EE itself?
  • well, I'm very happy to say that I've thrown thousands of drones and other AI ships in through my test script, and the engine is running really solid. Yes, when there's about 500+ entities all going at it simultaneously in one big furball it does slow down a bit, but it chugs along quite well and grinds down the ships and then just settles down and keeps plugging along. Same script run (w/o shutting it down), I've literally put through hundreds in successive waves adding up to several thousands of destroyed AI drones/ships, and it's solid. Thank you again daid! 8-)
  • Previous versions of EE used an older version of drmingw crash reporter, so most likely a version compattible with that is somewhere on your system. Also explains why it works if you rename the dll.
  • aha! yes, I have several versions of EE 'installed' on this machine, but really don't need them there. I have just been lazy about removing them. Now, given there isn't an msi associated with the files, I would normally just delete the old EE files, but this sounds like an extra step needs to be done? Use the normal Win program uninstall feature? What would be best recommendation?
  • Well, EE normally never installs anything, especially not in the global path of windows (I hate it when software does that)

    So my guess would actually be that some other piece of software installed those dlls somewhere.
  • yup, that was my inclination as well. ok, I'll go on a hunt! Tks for the help!
  • btw, what's the impact if I can't fix it other by keeping the file in the EE directory a different name?
  • It will work fine. dlls are a bit designed to be exchangable. You simply have a different version of the crash reporter then, but it will still work. And even it that bugs out, it will only bug out when it crashes. So little harm done.
  • edited September 2019
    There were reports that without javascript the download page links to http://daid.eu/ee/downloads/?C=M;O=D where the newest versions are missing. So it should point to https://github.com/daid/EmptyEpsilon/releases instead.
  • edited September 2019
    There is another user that had a very similar error message to to the one kilted klingon experienced, however, this time it was about mgwhelp.dll
    The procedure entry point MiniDumpReadDumpStream could not be located in the dynamic link library mgwhelp.dll

    Deleting/Renaming it does not seem to help here. So there seem to be a more serious problem than we thought.
  • Just tried the rpi4 as a server and viewscreen on debian buster. No crashes but the framerate at 1080 is about 0.5 :P
  • @croxis which driver did you use? There is a is a video on youtube where the framerate is way higher than that. It was on the 4GB version, however.
  • default for buster, which i think is the opengl driver
  • Default is most likely software rendering. As i got around 20-30 fps on the pi2 with the hardware opengl driver. But that is listed as experimental.
Sign In or Register to comment.