An update for those interested, I determined Enigma was calling the wrong compiler when compiling for Android and with the help of Josh we tracked it down to my broken Android.ey file.

Now the problem we have is that apparently the Android g++ fails to invoke cc1plus when compiling Enigma. Even trying to manually compile 1 file fails. I will try manually compiling one of the NDK samples later in this manner to see if it results in the same error. If it does... there is some serious black magic going on behind the scenes.

EDIT:
Further update... the gcc binaries being in a non-standard place did not know where to look for cc1plus. I switched to using the standard bin directory with ugly-named gcc binaries, but compilation started!

The new problems I have are compilation problems. Mainly, OpenGLES is just screwed. It hadn't been updated in who knows how long, and a lot of Enigma's structure has changed in that time. I have been plowing away it it, but I fear I am in way over my head at this point. Fixing compilation errors results in other compilation errors! I will torture Josh if he is on IRC tomorrow (today?).

In the mean time, such fun errors include...

Code Select Expand

./Graphics_Systems/OpenGLES/../General/GSfont.h:36:42: error: 'variant' has not been declared
./Graphics_Systems/OpenGLES/../General/actions.h:47:9: error: 'object_planar' is not a member of 'enigma'
./Graphics_Systems/OpenGLES/../General/actions.h:249:69: error: 'background_replace' was not declared in this scope
./Collision_Systems/actions.h:28:103: error: 'struct enigma::inst_iter' has no member named 'inst'
./Graphics_Systems/OpenGLES/../General/GSscreen.h:29:8: error: ambiguates old declaration 'void enigma_user::screen_redraw()'
c:/androidtoolchain/lib/gcc/../../include/c++/4.6/bits/basic_string.tcc:221:5: note: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::basic_string<_CharT, _Traits, _Alloc>::size_type, _CharT, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = unsigned int]
c:/androidtoolchain/lib/gcc/../../include/c++/4.6/bits/basic_string.tcc:221:5: note:   candidate expects 3 arguments, 1 provided


And so much more! OpenGLES may have to be rewritten from the ground up! I also propose the starting of OpenGLES2 as a separate and shiny new Graphics subsystem! (Hell, maybe we ditch GLES1 entirely!)

You can also temporarily rename your MinGW directory (or unlink it from the path) and see if make.exe complains.

The Enigma plugin does not load if it cannot find make.exe.

A quick way to test that is to call it with -v.

Ah well apparently it is using the right one when attempting an Android compile (by the way interesting the way Enigma works in this regard!)

C:/android-ndk-r8e/prebuilt/windows-x86_64/bin/make -v

Any other ideas?

I wasn't able to get very far, but it seemed that most times when I clicked somewhere to go it would bring me somewhere else or zoom in too far for me to even tell what I was looking at. I don't know if it's a bug in the Windows version of the game or if I'm just bad at it :p.

He used to be a pretty helpful person, but over the past few years he's gotten quite mean. As to why he doesn't get warned or banned, he simply skirts the line without really crossing it. I honestly don't know why he spends so much of his life patrolling the GMC though, I guess he has nothing better to do.

There really isn't a guide on building manually, and the documentation included in the NDK is very sparse.

The only thing I can think of right now (after some more toying with this) is that SYSROOT might have to be defined earlier in the compile process than the Android makefile. I have no other idea how mingw's libstdc++ files are being included.

My only other guess is that the make.exe I am calling is not using the correct GCC. It smells suspiciously like it's using mingw instead of the ndk... but I have no idea how to prove or fix that.

Hello we are aware of this, and as Darkstar2 notes it is because it is packaged with the 7-zip self extractor. Chrome doesn't like it for some reason. The solution (aside from waiting for Chrome to not flag it) is to use a different method of packaging, whether it be an installer or a plain .zip file.

I really like the customizability of it as well. Don't like Unity? Try Gnome or KDE or XFCE or LXDE or...

If it were possible to get all of my software running successfully under Linux, I would switch to it in a heartbeat. However as a game developer, you are often platform locked. E.g. Windows Phone, iPhone.

The first two I don't think you'd be able to find much of an audience on iTunes, just due to how ambient they are. You'd probably have  better luck selling them on some sort of audio resource site.

Anyway, I've only ever released one song: https://soundcloud.com/blandnonsense

I was planning on using it for one of my games, but never got around to finishing it.

You're most likely right about it being the fault of the VM. My guess would be you don't have hardware acceleration in there, and Enigma compiled games don't know how to deal with that. Just a guess, of course. You could upload the .exe produced and I can tell you if it runs on my machine, so you'd not have to wait until you can boot up a Windows partition.

In ENIGMAsystem\Additional\i686-w64-mingw32\lib I have all of those libraries.

I think the directory structure changed between when the Windows patch was created and now.

In the zip file there is ENIGMAsystem\Additional\Windows. Copy the contents of that Windows folder to ENIGMAsystem\Additional\YOURCOMPILER\ and see if it works.

Hi thanks for the info. It looks like the data is loaded correctly, but not associated with the tree node. I'm looking into it at the moment and I'll leave a note if I'm able to find a fix.

Hi, I've tried your file myself and I was able to open it without crashing. I have the same Java and Windows versions as you, but I am running 64 bit. How recently have you updated Enigma? I am using the latest Windows portable.

This topic might have been better suited for the Issues Help Desk but I don't think it matters much.

The self-extracting installer from 7/1 was also flagged as malicious for me in Chrome (which Robert had packaged). I packaged the latest version, but I also used 7zip self-extracting exe and it is also flagged. The solution is to download from another browser, or change the setting in Chrome. Or of course we could package as .7z or .zip.

I have a spare Linux server I could set up to automatically update a Windows .7z and .zip if there was enough interest. Otherwise I could just do the same manual packaging every week or two.

I created one and updated the wiki page ( http://enigma-dev.org/docs/Wiki/Install:Windows ). Let me know if it works, I don't think I made it precisely the way Robert used to.

I'm just gonna throw this out there: would it be better to try to get the ndk-build script to compile all of Enigma? I don't know if it's possible to get the Android.mk file to (a) Compile other makefiles, or (b) compile source code that is not inside of a "jni" directory.

I'll look into this more myself once I'm feeling a bit better, but this might be a better solution than trying to deduce by what black magic the linker links.