Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Goombert

Issues Help Desk / Re: after i call game_end game process stuck
« on: January 19, 2015, 05:36:44 pm »
What operating system and version are you running this on? It seems like you need to debug your drivers, I really don't see how OpenAL could be failing to close.

Issues Help Desk / Re: Linux Unable to load library 'compileEGMf'
« on: January 19, 2015, 05:33:06 pm »
Don't worry I fixed it and this time made sure to build for both Mingw64 and 32.

Just undo all your changes, cd to enigma-dev git reset --hard and then git fetch and git pull. Then it should build, you don't need to run python

Issues Help Desk / Re: Linux Unable to load library 'compileEGMf'
« on: January 19, 2015, 03:32:01 pm »
The reason is because size_t is not unsigned on a 64bit system, though it really has nothing to do with your OS, but your compiler, and you're on the same GCC as the portable and myself.

To get around this right now just undo the changes I made in the other topic.

Look at the git commit links and just do the opposite of what I did in those changes and it should build and work fine. Or just wait for me to ask Josh and fix it the correct way.

Issues Help Desk / Re: after i call game_end game process stuck
« on: January 19, 2015, 03:30:14 pm »
Actually the gdb tells us exactly why it is failing. OpenAL is failing to close a device which is why it's becoming an inferior process. You are on Windows XP, correct? Have you used other OpenAL applications before?

Issues Help Desk / Re: Linux Unable to load library 'compileEGMf'
« on: January 19, 2015, 03:20:18 pm »
Well this is just great, it looks like size_t is defined as unsigned on your system, can you gcc --version for me?

It would be working if not for my changes over in the other topic to make MinGW64 able to build the compiler.

I have to talk to Josh.

Issues Help Desk / Re: sprite_add not working?
« on: January 19, 2015, 03:06:27 pm »
Quote from: Darkstar2
Robert, any idea why sprite_add no longer works ? It used to.
Does this answer your question?
Quote from: RobotiX
Fixed it. looking at the error it says "Arithmetic exception." and "width/imgnumb" I put two and two together and guessed that it was a divide-by-zero error, I changed image_num to 1 instead of 0 and it didn't crash.
Thanks Obama.
It's not broke and it hasn't been broke since I broke it to fix it.

Quote from: RobotiX
I get a "Unknown function or script `sound_fade'" error regardless of which sound system I'm using.
It looks like we never actually even outlined the function. I can give you the basic steps to add it though.
First outline the function in the general header
it should be the same path in your local enigma-dev copy regardless of how you installed. By outlining it there it ensures the parameter and return types are the same for every system.
Then you just add the body of the function in
for OpenAL. That's really all you need to do and the function will be usable, you could also send us a pull request on GitHub and we may merge it so long as you write the code neatly to match the other functions in the files.

Quote from: GM8.1 Manual
sound_fade(index,value,time) Changes the volume for the indicated sound to the new value(0 = low, 1 = high) during the indicated time (in milliseconds). This can be used to fade out or fade in music.

Issues Help Desk / Re: after i call game_end game process stuck
« on: January 18, 2015, 06:35:02 pm »
Hello qwerty, do you know how to run the game in GDB? That would be extremely useful I fixed bugs before regarding game_end however I have no encountered any for a while. If you can GDB it for me and provide a stack trace that would be extremely useful.

Are you by chance also passing a value to game_end? ENIGMA's game_end works slightly differently than GM's and allows you to specify the return value, you could in fact try game_end(32); or some unique number to check it.

Issues Help Desk / Re: sprite_add not working?
« on: January 18, 2015, 06:21:12 pm »
Quote from: RobotiX
Thanks Obama.
lol, Howdy, I am Robert and I have done a lot of contributing here so I may be able to clarify some things for you.

Currently OpenAL attempts to implement both the basic sound functions and DirectSound functions, however we eventually plan to drop support for the sound_* functions unless you use the DirectSound system. audio_* functions are from GM: Studio which uses OpenAL and is better for both cross-platform development as well as positional audio, DirectSound is deprecated by Microsoft. The original sound_* functions from GM 8.1 and earlier were implemented with DirectSound and mp3 files were played using DirectMusic which is an interface for Windows Media Player (hence the old option to use an external media player). ENIGMA's DirectSound system does not implement DirectMusic yet so it only supports basic WAV formats. I am certain our OpenAL system supports OGG, WAV, and MP3 because we built it with those codecs.

I am sorry you encountered the bug ENIGMA certainly needs better error handling, and there is discussion about the interface design for it but that is mainly in the context of compile-time errors and not run-time errors. There have been some things I have been planning regarding ENIGMA's run-time exceptions and that is mainly to provide a stack trace with line numbers in the function show_debug_message like LateralGM's exception dialog. One place we have improved recently is that undefined variables can actually report scope in debug mode, which was a huge improvement.

Developing ENIGMA / Re: MinGW 64
« on: January 18, 2015, 05:45:57 pm »
First, I'd like to point out that TDM GCC is garbage Harri, though it does support dual target, at this point I am pretty sure we will not go with dual target though it will be possible if somebody really wants to build 32bit games. The first objective here is to just get 64bit support working then we can work out the other details. But I think another change my come first. The Portable ZIP was designed with the Mingw32 from the official installer of the MinGW 64 project by fundies/cheeseboy from

I tested again to see if installing i686 (32 bit) would work with ENIGMA using COMMONPROGRAMFILES/mingw-w64\x86_64-4.9.2-win32-seh-rt_v3-rev1/ and it worked because these installers make sure the path does not contain spaces like the TDM GCC installer may do. This solution will still not work for the Windows SDK as that is a GNU Make problem. So the first step here may in fact be to remove mingw all together from the ZIP and go back to forcing you to install it. This will make smaller ZIP releases and allow me to release them more quickly. And I may decide to also make you install git if you optionally want it. This way you don't have to download our packaged versions each time you want to update, because really that is stupid.

It would just be nice for everyone to give me a yay or nay on this, I already know where Josh and I stand on removing mingw and git from the ZIP.

Edit: On a side note I have decided to create the following Wiki article that further explains the current state of using parallel Java installations with ENIGMA.

Developing ENIGMA / Re: MinGW 64
« on: January 17, 2015, 02:44:26 pm »
Windows 10 is still supporting 32bit though egofree, there's no hurt in supporting things even if not everyone needs them, especially when it's little effort. Right now I've included the compileEGMf fixes for MinGW64 above and Josh approves. So now the additional/include additional/lib folders need recompiled on Mingw64, I don't have any time right now or I would. Once that's done they just need included in a separate Portable ZIP with MinGW64 (SEH exception, Win32 threads; and x86_64 architecture) and we have a 64bit Portable ZIP.

Ok great yeah, it really should be in ProgramData because that is why Microsoft built the directory into the OS for specific reasons. If you need any more help let us know!

Developing ENIGMA / Re: MinGW 64
« on: January 17, 2015, 01:49:56 pm »
Darkstar2 that gets into 32bit vs 64bit, and I don't want to derail his topic too much but primarily 64bit apps can handle threads better and 32bit apps are limited by most operating systems to something like only 1GB of RAM usage. So yes 64bit does mean better performance for games. And I believe 64bit apps should still work on 32bit, it just means they may be kinda buggy, you can run 64bit Firefox on i686 but it won't really give you any performance boost.

The real reason for addressing this is so that users can use either 64bit or 32bit Java, I don't like telling people to have to install both of them in parallel, they should be able to use the Java installation they already have. LateralGM would also work better with the plugin in 64bit mode because it can be allotted more RAM.

Quote from: qwerty
(also i change temp dir from progdata to dir created by me)
Are you running with administrative priveleges? Right click ENIGMA.exe and select "Run as administrator" if you aren't using ProgramData then you need specific privileges for it, this is in fact why Microsoft created ProgramData, why would you need to change it?

Hey qwerty, it may actually be that you downloaded a newer version with some changes in the source. Try deleting the contents of the ProgramData folder, not the actual folder, just the ENIGMA stuff inside it, and then try running and building with ENIGMA again. Sometimes when you update the source code binaries are left over from the previous version.

Developing ENIGMA / MinGW 64
« on: January 17, 2015, 12:41:35 pm »
Ok so I decided to see what it would take to finally support 64bit in ENIGMA.

The first thing was getting JDI and the Compiler to build with MinGW64

Edit: Josh approves as of this commit.

Edit: Josh advised me to use the fixed size types for the overload, so now the compiler builds with C++11 support too for both 32bit and 64bit GCC

I should not have wrote those straight to master but they may need reverted, anyway...

64bit Java/JNA can only load 64bit dll's and 32bit Java/JNA can only load 32bit dll's. This means that the users Java installation with ENIGMA thanks to the plugin and using ENIGMA the way we do will have to match the architecture of that the user not only has but also intends to target.

So if you have 64bit Java, with any ENIGMA release you will only be able to make 64bit games. And if you have 32bit Java you can only build and use the 32bit version of ENIGMA. But you could install both 32bit and 64bit ENIGMA in parallel and Java in parallel to be able to build for both architectures if you have a 64bit OS.

One possible alternative is to remove the requirement of JNA and compileEGMf all together replacing it entirely with the CLI allowing you to build both 32bit and 64bit applications with either a 32bit or 64bit Java installation. We could then use a MinGW that supports dual target though the exception support would be pretty grotesque, just because that's the state of current dual target MinGW compilers. Another way of accomplishing the same thing is to build compileEGMf for the supported Java architectures which would still require a dual target MinGW.

1) Do we want both a 32 bit and 64 bit ENIGMA portable, or just a very large single ENIGMA portable? If the former you would have to download both portables in order to build for both architectures.
2) Do we want to be able to build 32 bit games when we have a 64 bit Java installed to run LGM?
3) This is tied to the first question, but do you want proper gcc exception support or not? Because if we go with dual target either 64bit exception support is bad or we maintain two separate releases. If not we could include both mingw32 and mingw64 instead of a dual target mingw64, and that may or may not mean we have two separate portables.

Addressing this problem would fix several issues.
1) 64bit Java would be supported to run ENIGMA
2) 64bit compilation support would be added.

For the record Qt Framework also makes you install separately, as does Java and .NET and a lot of other programs.

Note: The good news is also that JNA supports both 32bit and 64bit so there's no need to distribute two versions of it.