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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 »
436
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.
http://enigma-dev.org/forums/index.php?topic=2415
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.
To get around this right now just undo the changes I made in the other topic.
http://enigma-dev.org/forums/index.php?topic=2415
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.
437
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?
438
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.
http://enigma-dev.org/forums/index.php?topic=2415
I have to talk to Josh.
It would be working if not for my changes over in the other topic to make MinGW64 able to build the compiler.
http://enigma-dev.org/forums/index.php?topic=2415
I have to talk to Josh.
439
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
EDIT AGAIN:It's not broke and it hasn't been broke since I broke it to fix it.
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.
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 https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Audio_Systems/General/ASbasic.h#L62
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 https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Audio_Systems/DirectSound/DSbasic.cpp#L92
or https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Audio_Systems/OpenAL/ALbasic.cpp#L152
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.
440
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.
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.
441
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.
442
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 http://sourceforge.net/projects/mingw-w64/
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.
http://enigma-dev.org/docs/Wiki/Install:Parallel_Java
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.
http://enigma-dev.org/docs/Wiki/Install:Parallel_Java
443
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.
444
Issues Help Desk / Re: Unknown function or script/events dont work in second project
« on: January 17, 2015, 01:55:47 pm »
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!
445
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.
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.
446
Issues Help Desk / Re: Unknown function or script/events dont work in second project
« on: January 17, 2015, 01:28:36 pm »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?
447
Issues Help Desk / Re: Unknown function or script/events dont work in second project
« on: January 17, 2015, 01:06:59 pm »
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.
448
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
https://github.com/enigma-dev/enigma-dev/commit/331235e30f971ca7e38393efe1423cd38f1ff027
https://github.com/enigma-dev/enigma-dev/commit/f1e8cfdd0d55e6b901fef60dce19781f43d36859
https://github.com/enigma-dev/enigma-dev/commit/355d2d8fd8c5d17fa7232034a18d63475658a4f5
Edit: Josh approves as of this commit.
https://github.com/enigma-dev/enigma-dev/commit/9d49bf81c81106f8d8ed78d60c03001681a15c31
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
https://github.com/enigma-dev/enigma-dev/commit/5b99151173b1dad9acb059f9e99a75974801d42b
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.
https://github.com/enigma-dev/lgmplugin/issues/20
For the record Qt Framework also makes you install separately, as does Java and .NET and a lot of other programs.
https://www.qt.io/download-open-source/#section-3
Note: The good news is also that JNA supports both 32bit and 64bit so there's no need to distribute two versions of it.
The first thing was getting JDI and the Compiler to build with MinGW64
https://github.com/enigma-dev/enigma-dev/commit/331235e30f971ca7e38393efe1423cd38f1ff027
https://github.com/enigma-dev/enigma-dev/commit/f1e8cfdd0d55e6b901fef60dce19781f43d36859
https://github.com/enigma-dev/enigma-dev/commit/355d2d8fd8c5d17fa7232034a18d63475658a4f5
Edit: Josh approves as of this commit.
https://github.com/enigma-dev/enigma-dev/commit/9d49bf81c81106f8d8ed78d60c03001681a15c31
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
https://github.com/enigma-dev/enigma-dev/commit/5b99151173b1dad9acb059f9e99a75974801d42b
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.
https://github.com/enigma-dev/lgmplugin/issues/20
For the record Qt Framework also makes you install separately, as does Java and .NET and a lot of other programs.
https://www.qt.io/download-open-source/#section-3
Note: The good news is also that JNA supports both 32bit and 64bit so there's no need to distribute two versions of it.
449
Issues Help Desk / Re: Create games for mobile platforms is possible with enigma??
« on: January 16, 2015, 06:07:24 pm »
egofree is exactly right the problem is not Java, even GM8.1 loaded giant binary blobs in Delphi. Second egofree, to replace it with my CLI project you would first have to fix my CLI because it was broken when preCreateCode was added and I haven't managed to get it working because of other changes. But using it would basically mean getting rid of GMK support in LGM. I mean the CLI can load and compile a GMK no problem. But for the CLI to make LGM itself more efficient requires LGM to not load the entire project into memory at once, but load each resource as you open it. So for instance when you open a script, that is when the script is loaded into memory, and when you close it is unloaded from memory. Right now LGM loads every resource into memory when you load the project and keeps it there until you close or load another project.
Then when you hit run LGM does not have to pass anything to ENIGMA, it just makes you save open resources like all other IDE's including Studio's now. Studio does it this way and makes you convert GMK's to GMX when you load them. Then LGM just passes the path to your project to the CLI and the CLI handles all the compiling with native C++. So you can see why it is more efficient and why this can't be easily done with GMK. With GMK it is impossible to just load a single resource because it is a huge binary blob, and that is why Studio makes you convert to GMX.
But primarily GMK projects are where ENIGMA has the best support right now, and one of the primary reasons LGM is still used, and in fact recommended by some GMC moderators is because it can be used in fixing corrupted GMK's where GM8.1 has failed.
And Darkstar2 while you may be right about ENIGMA being better if it were its own project, which I've argued before. Doing that would essentially destroy the very reason many people show up, to compile GM projects, which is why I showed up here and ported my Project Mario game to ENIGMA so that it would run natively. While this may be the exception and not the rule with me and Sorlok, the project would be missing two very important contributors, not to degrade the importance of other contributors of course because I am not really sure why egofree contributes other than just like me he just likes to help.
Additionally settings.ini is not a hack, LGM does in fact have 64bit support and so does the plugin. It's in fact ENIGMA that does not have 64bit support. But the plugin is where most of the instability exists.
Then when you hit run LGM does not have to pass anything to ENIGMA, it just makes you save open resources like all other IDE's including Studio's now. Studio does it this way and makes you convert GMK's to GMX when you load them. Then LGM just passes the path to your project to the CLI and the CLI handles all the compiling with native C++. So you can see why it is more efficient and why this can't be easily done with GMK. With GMK it is impossible to just load a single resource because it is a huge binary blob, and that is why Studio makes you convert to GMX.
But primarily GMK projects are where ENIGMA has the best support right now, and one of the primary reasons LGM is still used, and in fact recommended by some GMC moderators is because it can be used in fixing corrupted GMK's where GM8.1 has failed.
And Darkstar2 while you may be right about ENIGMA being better if it were its own project, which I've argued before. Doing that would essentially destroy the very reason many people show up, to compile GM projects, which is why I showed up here and ported my Project Mario game to ENIGMA so that it would run natively. While this may be the exception and not the rule with me and Sorlok, the project would be missing two very important contributors, not to degrade the importance of other contributors of course because I am not really sure why egofree contributes other than just like me he just likes to help.
Additionally settings.ini is not a hack, LGM does in fact have 64bit support and so does the plugin. It's in fact ENIGMA that does not have 64bit support. But the plugin is where most of the instability exists.
450
Issues Help Desk / Re: Create games for mobile platforms is possible with enigma??
« on: January 16, 2015, 03:49:21 pm »
I know ego, but specifically what I am trying to point out to you is that i did in fact make substantial progress, it's not about what I did, it's that you don't need to worry about me doing plenty of different things because I historically finished them, a lot of them. And yes I agree the scope of the project is way too big, but I have no solutions for fixing that, for a while I was the solution.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 »