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 »
76
Off-Topic / Re: Greetings, everyone!
« on: December 05, 2018, 12:41:19 am »
Hey ProtoLink! I should mention I find it humorous that not only is your group Enigma, your name is also "Proto" "Link" and the entire new serialization mechanism we use in the new IDE is based on Google Protocol Buffers (aka "protos"). Anyway, welcome to the forum and I hope you have fun here! Our community members are extremely helpful so don't ever be afraid to ask for help.
77
Issues Help Desk / Re: LGM/Enigma lib errors
« on: December 05, 2018, 12:37:52 am »Quote
3. 64-bit CompileEGMF don't work on latest LateralGM.
Quote
I'm using portable Java 8.0 x32, packed with Launch4j, so, the installation and PATH for it is not needed.
This is the problem, you have to use a Java that is the same architecture as compileEGMf. A 64 bit Windows process can not load a 32 bit dll, and this is true for Java as well. If your computer can run the 64 bit version, then you should use a 64 bit Java with a 64 bit MSYS2, which actually will still allow you to build 32 bit games if you separately install the 32 bit versions of the packages at the same time (though nobody has really experimented with doing so yet). RadialGM will not have this issue.
78
Issues Help Desk / Re: RGM crashes on startup
« on: November 17, 2018, 04:07:15 am »
This has since been resolved and was just temporary. Understand I may make a few more breaking changes like this as I refine the remote building of games in the server.
https://github.com/enigma-dev/RadialGM/commit/cd8ff62dc5dd3da1d10f6baa2f4e136688d5f090
https://github.com/enigma-dev/RadialGM/releases/tag/RadialGM-v1.0.126
That said, I am not really ready for beta testing yet, so whatever people are doing at this point is not really supported. I'll be making an official announcement when everything is ready to go for the first beta.
https://github.com/enigma-dev/RadialGM/commit/cd8ff62dc5dd3da1d10f6baa2f4e136688d5f090
https://github.com/enigma-dev/RadialGM/releases/tag/RadialGM-v1.0.126
That said, I am not really ready for beta testing yet, so whatever people are doing at this point is not really supported. I'll be making an official announcement when everything is ready to go for the first beta.
79
Issues Help Desk / Re: LateralGM external code editor does not work
« on: November 17, 2018, 04:00:07 am »
Sorry I do not have more time to investigate with developing the new IDE full time. I just want to post to let you know I think I might know the answer to your problem. After configuring an external code editor you may need to reopen any scripts/code windows or completely restart. When you do, you should then see a pencil icon on the toolbar of the code editor. That pencil icon will open the script/code in the external editor. We could discuss improving on this in LGM, but iirc GM was always the same way, and I am no longer supporting LGM with the new IDE on the way.
You should check the following Wiki guide instead of the other one:
https://enigma-dev.org/docs/Wiki/Overriding_settings
The one Hugar is referring to is just how to make Notepad++ have GML syntax highlighting which is independent of using it with ENIGMA or GM.
You should check the following Wiki guide instead of the other one:
https://enigma-dev.org/docs/Wiki/Overriding_settings
The one Hugar is referring to is just how to make Notepad++ have GML syntax highlighting which is independent of using it with ENIGMA or GM.
80
Off-Topic / Re: absolutely important announcement
« on: October 30, 2018, 10:38:04 am »
I want to take a moment to say, yes, I too am very thankful for HitCoder. I also consider him my friend, he's a good guy, and actually he's very special. If he were to leave I would feel like this community were missing something very important. I would say I have similar sentiments about the lot of you too.
I want to also say that it's because of appreciation for every member's contribution here that I take extra precaution when refactoring the codebase. Moreso in recent years than before and we've done a great job of preserving many of the bug fixes and patches everybody has submitted over the years despite major overhauls I've been doing to the frontend and the graphics.
Everybody is welcome here to make games and you should never feel otherwise.
I want to also say that it's because of appreciation for every member's contribution here that I take extra precaution when refactoring the codebase. Moreso in recent years than before and we've done a great job of preserving many of the bug fixes and patches everybody has submitted over the years despite major overhauls I've been doing to the frontend and the graphics.
Everybody is welcome here to make games and you should never feel otherwise.
81
Tips, Tutorials, Examples / Re: Debugging Your Project: Finding Memory Leaks
« on: October 30, 2018, 10:26:52 am »
Thanks so much for sharing these pro tips with the community Hugar! I am going to set this topic sticky for now, later a section could be added to the Wiki about this.
https://enigma-dev.org/docs/Wiki/Debugging
I too would like to see a built-in memory leak detector, perhaps we can get to it someday with RGM. For now, using the test-harness is a perfectly acceptable approach to dealing with this.
https://enigma-dev.org/docs/Wiki/Debugging
I too would like to see a built-in memory leak detector, perhaps we can get to it someday with RGM. For now, using the test-harness is a perfectly acceptable approach to dealing with this.
82
Works in Progress / Re: Witch Blast
« on: October 30, 2018, 10:21:00 am »
Hi rcobra! I would gladly give the game a test if there were a Windows build. Now, I know there may be some problems right now setting up the Windows ENIGMA hehe, but I can also help with the new MSYS2 setup. Though, I know you still have the open issue on GitHub with respect to Linux gamepads, I don't know if you've even tried the Windows MSYS2 setup yet? If not, that's ok, I will also test your game the next time I happen to be in possession of a working Linux VM.
83
General ENIGMA / Re: Enigma on ARM Linux
« on: October 30, 2018, 10:15:12 am »
Hey Wendigo, I will try to offer some advice though my experience here is limited too. First, it doesn't surprise me Java would be an issue. But that's ok, if you want to use the command line you don't need Java now, that's just if you want to edit and run the game with LGM. Because I have been busy trying to focus on RGM, we haven't quite documented how to use the new command line as much, but it's pretty simple.
The process is well documented for Windows:
https://enigma-dev.org/forums/index.php?topic=2939.msg27287#new
You just need a few additional packages such as protobuf, pugixml, yaml-cpp, and rapidjson. The best place to find the packages that you need for your Linux distribution is probably the Travis CI yaml file in our repo since the CI we run on every pull request builds the command line.
https://github.com/enigma-dev/enigma-dev/blob/128d62949f988ef747f6926111fb11ae841558ad/.travis.yml#L17
You'll probably want to do a clean build, so I'd run [snip]make clean[/snip] first. Then you'll just want to run [snip]make emake[/snip] to build the C++ CLI. Once you've successfully built emake, instructions for running it can be found on the wiki.
https://enigma-dev.org/docs/Wiki/Command_line_interface
In the future we can look at building a new debian package for emake. Right now my priority is getting an RGM beta out to start replacing LGM with it. RGM is not just a different IDE but builds your game using the same underlying tools as emake. In this way, an IDE like LGM or RGM is considered supplementary or optional.
The process is well documented for Windows:
https://enigma-dev.org/forums/index.php?topic=2939.msg27287#new
You just need a few additional packages such as protobuf, pugixml, yaml-cpp, and rapidjson. The best place to find the packages that you need for your Linux distribution is probably the Travis CI yaml file in our repo since the CI we run on every pull request builds the command line.
https://github.com/enigma-dev/enigma-dev/blob/128d62949f988ef747f6926111fb11ae841558ad/.travis.yml#L17
You'll probably want to do a clean build, so I'd run [snip]make clean[/snip] first. Then you'll just want to run [snip]make emake[/snip] to build the C++ CLI. Once you've successfully built emake, instructions for running it can be found on the wiki.
https://enigma-dev.org/docs/Wiki/Command_line_interface
In the future we can look at building a new debian package for emake. Right now my priority is getting an RGM beta out to start replacing LGM with it. RGM is not just a different IDE but builds your game using the same underlying tools as emake. In this way, an IDE like LGM or RGM is considered supplementary or optional.
84
Issues Help Desk / Re: Win32 Enigma missing ffi.h
« on: October 18, 2018, 06:17:00 am »
I see, I am not surprised, this has already been reported by Hugar actually:
https://github.com/IsmAvatar/LateralGM/issues/377
I know what the issue is already actually. The sprite subframe list is being iterated on close and modifying the list while iterating it. That's what a concurrent modification is. You have to do special things, even in C++, when mutating any kind of data structure you happen to be iterating over at the same time. That said, I tried fixing it when hugar reported it, but Java sucks so badly none of the solutions for iterating the list and adding/removing from it at the same time that I sent to him worked. So I am sort of convinced it may actually be a Java bug, but can't say for certain. I am also on Windows 10 and have not encountered the issue myself.
I apologize that I do not have more time to invest in fixing this right now as I am trying to prioritize RadialGM which will be much better and solve a lot of our issues. I very strongly dislike Java after all of the experience developing for it that I have obtained. It's just a complete mess to write working applications for the Java platform when there's multiple JDKs with multiple Java API implementations just on a single platform. That and the fact that we can't control the dependencies (like Java Swing version) our users end up trying ENIGMA with, makes the situation all the more serious.
For these reasons, I believe that LateralGM is going to stop working soon to the point we won't be able to maintain it so I am focusing all my energy on RadialGM in order to save the project. The setup is going to be a lot easier as well, no installation of Java, just drag and drop RadialGM exe into your enigma-dev folder. Just yesterday I got compiling games working.
Anyway, sorry to divert from your issue, I just want to be clear why I can't offer much more help on any LGM issues right now. I hope you understand and that maybe I helped a little bit, and please stay tuned for more information about the upcoming IDE!
https://github.com/IsmAvatar/LateralGM/issues/377
I know what the issue is already actually. The sprite subframe list is being iterated on close and modifying the list while iterating it. That's what a concurrent modification is. You have to do special things, even in C++, when mutating any kind of data structure you happen to be iterating over at the same time. That said, I tried fixing it when hugar reported it, but Java sucks so badly none of the solutions for iterating the list and adding/removing from it at the same time that I sent to him worked. So I am sort of convinced it may actually be a Java bug, but can't say for certain. I am also on Windows 10 and have not encountered the issue myself.
I apologize that I do not have more time to invest in fixing this right now as I am trying to prioritize RadialGM which will be much better and solve a lot of our issues. I very strongly dislike Java after all of the experience developing for it that I have obtained. It's just a complete mess to write working applications for the Java platform when there's multiple JDKs with multiple Java API implementations just on a single platform. That and the fact that we can't control the dependencies (like Java Swing version) our users end up trying ENIGMA with, makes the situation all the more serious.
For these reasons, I believe that LateralGM is going to stop working soon to the point we won't be able to maintain it so I am focusing all my energy on RadialGM in order to save the project. The setup is going to be a lot easier as well, no installation of Java, just drag and drop RadialGM exe into your enigma-dev folder. Just yesterday I got compiling games working.
Anyway, sorry to divert from your issue, I just want to be clear why I can't offer much more help on any LGM issues right now. I hope you understand and that maybe I helped a little bit, and please stay tuned for more information about the upcoming IDE!
85
Issues Help Desk / Re: Win32 Enigma missing ffi.h
« on: October 17, 2018, 10:13:38 am »
Hey thanks for letting us know about this, I need the MSYS2 setup to work flawlessly for the fast-approaching RadialGM beta. Please let me know if you find anything else out in regards to this. It could have been any number of things including a recent change/update to the MSYS2 packages or perhaps you skipped the package containing that header during setup. If you do find anymore info, I'll keep track and make an announcement if I think it will be helpful to people. That said, I'm glad you did get it working!
86
Issues Help Desk / Re: Addressed variable doesn't get refreshed
« on: October 09, 2018, 10:01:40 pm »
You're welcome and yeah, just like you did was what I was suggesting. Sorry I can't look into it deeper right now because I am trying to direct all my focus and attention at rapidly getting the new RGM IDE to beta with fundies help. With Java going the way that it is, we simply can't keep up with it fast enough for me to even attempt maintaining LGM and if it continues we'll soon be out of an IDE altogether, hence my attention to RGM. I promise when we get into a better position, I will be devoting more time back to fixing engine bugs for people again and as I linked we already have an issue filed for the backgrounds issue.
The background tiling I don't believe has anything to do with it, we are just bounding the draw background in our [snip]screen_redraw[/snip] to the room area. That needs fixed and so do the other draw_background tiled functions but I need time to test all of those. Sorry, but I will get to it at some point. Feel free to try working around the issue for now or if somebody else wants, send the pull request to GitHub.
The background tiling I don't believe has anything to do with it, we are just bounding the draw background in our [snip]screen_redraw[/snip] to the room area. That needs fixed and so do the other draw_background tiled functions but I need time to test all of those. Sorry, but I will get to it at some point. Feel free to try working around the issue for now or if somebody else wants, send the pull request to GitHub.
87
Announcements / Re: MSYS2, Pacboy, and Virtual Packages
« on: October 09, 2018, 08:16:24 pm »
Sorry, Turbine, you are in fact correct that there are still some issues there. This revelation came to me thanks to HitCoder over Discord who was having trouble setting up a 32 bit installation.
The issue here is that there are actually 3 separate make packages that can be installed. There is a global MSYS one and two MinGW ones (one for each architecture). The MSYS one happens to be a virtual package just like git is and must be installed accordingly. So I have updated the Wiki instructions again.
https://enigma-dev.org/docs/wiki/index.php?title=Install%3AWindows&action=historysubmit&diff=31854&oldid=31853
To install the needed make packages you actually need to do:
The [snip]toolchain[/snip] group includes the MinGW make and the [snip]make:[/snip] virtual package includes the MSYS one. Sorry about all the confusion, and I think this should finally resolve this issue.
The issue here is that there are actually 3 separate make packages that can be installed. There is a global MSYS one and two MinGW ones (one for each architecture). The MSYS one happens to be a virtual package just like git is and must be installed accordingly. So I have updated the Wiki instructions again.
https://enigma-dev.org/docs/wiki/index.php?title=Install%3AWindows&action=historysubmit&diff=31854&oldid=31853
To install the needed make packages you actually need to do:
Code: (bash) [Select]
# 64 bit
pacboy -S toolchain:x make:
# 32 bit
pacboy -S toolchain:i make:
The [snip]toolchain[/snip] group includes the MinGW make and the [snip]make:[/snip] virtual package includes the MSYS one. Sorry about all the confusion, and I think this should finally resolve this issue.
88
Announcements / Re: MSYS2, Pacboy, and Virtual Packages
« on: October 04, 2018, 03:51:41 pm »
Edit: This post is incorrect slightly, please read my second reply below!!!
Hi Turbine! There's actually no need because the [snip]toolchain:x[/snip] package that is in the list already includes make.
Hi Turbine! There's actually no need because the [snip]toolchain:x[/snip] package that is in the list already includes make.
Quote from: MinGW64 Pacboy
$ pacboy -S toolchain:x
:: There are 17 members in group mingw-w64-x86_64-toolchain:
:: Repository mingw64
1) mingw-w64-x86_64-binutils 2) mingw-w64-x86_64-crt-git
3) mingw-w64-x86_64-gcc 4) mingw-w64-x86_64-gcc-ada
5) mingw-w64-x86_64-gcc-fortran 6) mingw-w64-x86_64-gcc-libgfortran
7) mingw-w64-x86_64-gcc-libs 8) mingw-w64-x86_64-gcc-objc
9) mingw-w64-x86_64-gdb 10) mingw-w64-x86_64-headers-git
11) mingw-w64-x86_64-libmangle-git 12) mingw-w64-x86_64-libwinpthread-git
13) mingw-w64-x86_64-make 14) mingw-w64-x86_64-pkg-config
15) mingw-w64-x86_64-tools-git 16) mingw-w64-x86_64-winpthreads-git
17) mingw-w64-x86_64-winstorecompat-git
Enter a selection (default=all):
89
Announcements / MSYS2, Pacboy, and Virtual Packages
« on: October 01, 2018, 07:53:45 pm »
I want to take a quick minute to explain a little bit about Pacboy because Hugar brought a user's installation issues to my attention over Discord. You can consider this post to be a sort of technical explanation and not really an announcement, but I want to try to clarify this for everybody and not just the one person.
The user was having a problem installing git using Pacboy because I forgot a colon on the install page for Windows. The [snip]git[/snip] package in MSYS2 is actually what's called a "virtual" package.
https://github.com/msys2/msys2/wiki/Using-packages#installing-a-package
Because the package is virtual, when you install it with Pacman, you only need to specify [snip]git[/snip] without any [snip]x86_64[/snip] or [snip]i686[/snip] suffix. Now what Pacboy is, is it's a bash script written by the MSYS2 people that makes it easier to install Pacman packages so you don't have to specify the long package suffixes.
https://github.com/msys2/msys2/wiki/Using-packages#avoiding-writing-long-package-names
Long story short, with Pacboy the [snip]:x[/snip] is for x86_64 (64 bit) and [snip]:i[/snip] is for i686 (32 bit) just as our instructions said before, but a plain [snip]:[/snip] after the package name, like [snip]git:[/snip], should be used for virtual packages.
I've updated our Windows installation instructions to clarify all of this.
https://enigma-dev.org/docs/wiki/index.php?title=Install%3AWindows&action=historysubmit&diff=31845&oldid=31833
The user was having a problem installing git using Pacboy because I forgot a colon on the install page for Windows. The [snip]git[/snip] package in MSYS2 is actually what's called a "virtual" package.
https://github.com/msys2/msys2/wiki/Using-packages#installing-a-package
Because the package is virtual, when you install it with Pacman, you only need to specify [snip]git[/snip] without any [snip]x86_64[/snip] or [snip]i686[/snip] suffix. Now what Pacboy is, is it's a bash script written by the MSYS2 people that makes it easier to install Pacman packages so you don't have to specify the long package suffixes.
https://github.com/msys2/msys2/wiki/Using-packages#avoiding-writing-long-package-names
Long story short, with Pacboy the [snip]:x[/snip] is for x86_64 (64 bit) and [snip]:i[/snip] is for i686 (32 bit) just as our instructions said before, but a plain [snip]:[/snip] after the package name, like [snip]git:[/snip], should be used for virtual packages.
Quote from: Pacboy Terminal Prompt
Pacboy 2016.6.24
Copyright (C) 2015, 2016 Renato Silva
Licensed under BSD
This is a pacman wrapper for MSYS2 which handles the package prefixes
automatically, and provides human-friendly commands for common tasks.
Usage:
pacboy [command] [arguments]
Arguments will be passed to pacman or pkgfile after translation:
For 64-bit MSYS2, name:i means i686-only
For 64-bit MSYS2, name:x means x86_64-only
For MSYS shell, name:m means mingw-w64
For all shells, name: disables any translation for name
For all shells, repository::name means repository/name
I've updated our Windows installation instructions to clarify all of this.
https://enigma-dev.org/docs/wiki/index.php?title=Install%3AWindows&action=historysubmit&diff=31845&oldid=31833
90
Issues Help Desk / Re: Addressed variable doesn't get refreshed
« on: October 01, 2018, 01:06:33 am »
Hi, Woffelson! Allow me to address some of the points of your post here. ENIGMA, being open source, understandably has some differences from GM. In recent months though, we've been taking a lot of steps to address this including the addition of continuous integration, engine cleanup, abstraction, and additional testing. There is much work to be done still but things have demonstrably been improving.
https://github.com/enigma-dev/enigma-dev/issues/743
https://github.com/enigma-dev/enigma-dev/issues/851
I actually already apparently have an issue open for this that we haven't closed yet:
https://github.com/enigma-dev/enigma-dev/issues/646
We draw the tiled backgrounds here:
https://github.com/enigma-dev/enigma-dev/blob/4e8ad7c3857794f490610c621ae64ae54b3456b0/ENIGMAsystem/SHELL/Graphics_Systems/General/GSscreen.cpp#L83
[snip]draw_background_tiled_ext[/snip] is implemented here:
https://github.com/enigma-dev/enigma-dev/blob/4e8ad7c3857794f490610c621ae64ae54b3456b0/ENIGMAsystem/SHELL/Graphics_Systems/General/GSbackground.cpp#L217
If you want to experiment with the code in your local copy, changes to ENIGMA's source code take effect as soon as you save the source file and run the game again.
Quote
Deactivation/activation codes weren't working as they should.I am not surprised, we have some open issues in regards to instance activation and deactivation.
https://github.com/enigma-dev/enigma-dev/issues/743
https://github.com/enigma-dev/enigma-dev/issues/851
Quote
It seems that the activated region was locked to its beginning position.Your bug is interesting and sounds as if it could be related to the persistent rooms issue I linked above.
Quote
Maybe setting the variables in create event has something to do with this lockdown of id variables?Using [snip]show_message(str)[/snip] to verify all of your assumptions would be a great start if you really think that is the cause. It would also help with getting the bug fixed too, since finding the actual issue in a way that's reproducible is half the task of fixing it.
Quote
Oh, and other small thing: backgrounds doesn't seem to tile outside the room. (Quite annoying when trying to generate endless rooms.)Ah, I was curious about this one myself while going through the graphics code sometime recently. Luckily, we are actually in a much better position to fix this now that all of our background drawing code has been generalized (meaning we have only 1 version of the functions used by all graphics systems; D3D no longer has its own function different from GL).
I actually already apparently have an issue open for this that we haven't closed yet:
https://github.com/enigma-dev/enigma-dev/issues/646
We draw the tiled backgrounds here:
https://github.com/enigma-dev/enigma-dev/blob/4e8ad7c3857794f490610c621ae64ae54b3456b0/ENIGMAsystem/SHELL/Graphics_Systems/General/GSscreen.cpp#L83
[snip]draw_background_tiled_ext[/snip] is implemented here:
https://github.com/enigma-dev/enigma-dev/blob/4e8ad7c3857794f490610c621ae64ae54b3456b0/ENIGMAsystem/SHELL/Graphics_Systems/General/GSbackground.cpp#L217
If you want to experiment with the code in your local copy, changes to ENIGMA's source code take effect as soon as you save the source file and run the game again.
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 »