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 »
121
Issues Help Desk / Re: Compiling without Java or at least trough commandline
« on: November 27, 2012, 04:35:16 pm »
The enigma.jar itself can run independently of LGM as the cli. I believe if you try to run it without arguments (java -jar enigma.jar), it will indicate the arguments available. Either that or it will spout profanities at you. If it does that, just ask me and I'll look it up again.
122
Announcements / Thanksgiving Holiday Updates
« on: November 25, 2012, 10:18:53 pm »
Most of you probably haven't noticed this yet, because most of you don't bother to use the Tracker since it was quite broken - but Josh and I have put a little elbow grease into a new bug tracker idea to replace the old Bugspray system that broke after the last SMF update. We're happy to present it to you as a little Thanksgiving present. You can view it by clicking the Tracker link up top, as usual.
The new tracker utilizes the Github Issues system, and all old tickets will hopefully be migrated soon as well.
But wait, does this mean you'll need a github account to report a bug? And why do we bother to emulate it here, rather than just having a redirect?
No, that's where it gets clever! We've hooked up your forum/enigma-dev accounts to this system, so as long as you are logged in here, you can post or comment on issues without needing a github account. Technically, our old friend EnigmaBot posts on your behalf, but we try to keep that as transparent as possible so it doesn't look like every issue/comment was posted by EnigmaBot! One little quirk of this system is that posted issues created through the bot will have a [u###] in the title. This is just to help EnigmaBot to link your enigma-dev account.
If you do have a Github account, you may click on the link to Github and post/comment that way, if you'd prefer, or you can use our system and let EnigmaBot post on your behalf. When viewing issues here, anything posted by a github user will have their username italicized, and will link to their github profile; enigma-dev users will appear non-italicized, and will link to their enigma-dev profile. In the future, we may invest in linking accounts — ie, your ENIGMA account will keep track of the name of your GitHub account if you can prove your ownership thereof. In the meantime, you'll just have to put up with some issues and comments being from GitHub while others are from the forums.
Josh writes:
On a separate note, I cleaned up the forums a bit. You'll find the avatars section in your profile offers a default set of avatars again. If you don't have an avatar set, I encourage you to pick one as it makes skimming the forum and identifying people easier. Do not be surprised if I start assigning octocat to people.
Now, on to parser progress.
The "basics" are "working." This includes correct lexing around comments, macros, etc, which means that anything that works in C++ works in ENIGMA. However, I want far more than that, and so I've begun a specification page for features of EDL beyond those of GML. You can find the page on the wiki here.
Moreover, I am going to be maintaining an information page regarding adding export languages to ENIGMA. That page can be found here.
If there is anything you would like to see in ENIGMA which is not covered on that Wiki page, post about it here. I am in the process of adding some of my bullet points from the proposals board.
Hope those of you who had Thanksgiving celebrations enjoyed yourselves.
The new tracker utilizes the Github Issues system, and all old tickets will hopefully be migrated soon as well.
But wait, does this mean you'll need a github account to report a bug? And why do we bother to emulate it here, rather than just having a redirect?
No, that's where it gets clever! We've hooked up your forum/enigma-dev accounts to this system, so as long as you are logged in here, you can post or comment on issues without needing a github account. Technically, our old friend EnigmaBot posts on your behalf, but we try to keep that as transparent as possible so it doesn't look like every issue/comment was posted by EnigmaBot! One little quirk of this system is that posted issues created through the bot will have a [u###] in the title. This is just to help EnigmaBot to link your enigma-dev account.
If you do have a Github account, you may click on the link to Github and post/comment that way, if you'd prefer, or you can use our system and let EnigmaBot post on your behalf. When viewing issues here, anything posted by a github user will have their username italicized, and will link to their github profile; enigma-dev users will appear non-italicized, and will link to their enigma-dev profile. In the future, we may invest in linking accounts — ie, your ENIGMA account will keep track of the name of your GitHub account if you can prove your ownership thereof. In the meantime, you'll just have to put up with some issues and comments being from GitHub while others are from the forums.
Josh writes:
On a separate note, I cleaned up the forums a bit. You'll find the avatars section in your profile offers a default set of avatars again. If you don't have an avatar set, I encourage you to pick one as it makes skimming the forum and identifying people easier. Do not be surprised if I start assigning octocat to people.
Now, on to parser progress.
The "basics" are "working." This includes correct lexing around comments, macros, etc, which means that anything that works in C++ works in ENIGMA. However, I want far more than that, and so I've begun a specification page for features of EDL beyond those of GML. You can find the page on the wiki here.
Moreover, I am going to be maintaining an information page regarding adding export languages to ENIGMA. That page can be found here.
If there is anything you would like to see in ENIGMA which is not covered on that Wiki page, post about it here. I am in the process of adding some of my bullet points from the proposals board.
Hope those of you who had Thanksgiving celebrations enjoyed yourselves.
123
Announcements / Re: Commit Privileges
« on: November 25, 2012, 09:38:04 pm »
If you would like, we can make a branch for your changes so you don't need to fork the whole project. It's up to you.
124
Announcements / Re: Commit Privileges
« on: November 20, 2012, 01:59:01 pm »
Ah, I didn't think of the data being a collision line, rather than a collision point. Excellent, that'll work great, then, because the data is sorted (strange way to think of sorting, but again, the data is either 1 for collision or 0 for no collision, so as long as all data is contiguous except for the turnover point, it's sorted).
125
Announcements / Re: Commit Privileges
« on: November 19, 2012, 01:31:01 am »
That looks like Z-fighting. (Edit: Yup, you already figured it out)
As for the binary search, I must be misunderstanding where you plan on applying it, as it wouldn't work for a search loop, simply because of small objects being overlooked that way. A binary search is only useful on sorted data. In a collision search loop, there is no sorting. The data is 1's and 0's (collision or free), in no order.
forthevin: By the way, you can clump a bunch of similar changes together in 1 commit, or even make a group of commits and then squash them before pushing. That way the git doesn't seem flooded with small commits. Just a thought. You can do it however you want, since we're a small team.
As for the binary search, I must be misunderstanding where you plan on applying it, as it wouldn't work for a search loop, simply because of small objects being overlooked that way. A binary search is only useful on sorted data. In a collision search loop, there is no sorting. The data is 1's and 0's (collision or free), in no order.
forthevin: By the way, you can clump a bunch of similar changes together in 1 commit, or even make a group of commits and then squash them before pushing. That way the git doesn't seem flooded with small commits. Just a thought. You can do it however you want, since we're a small team.
126
Proposals / Re: Auto-completion option in the code editor
« on: November 09, 2012, 12:25:19 pm »
The code editor is still in need of heavy revision at this time - and is currently in the middle of being revised (although kinda on pause because of irl things)
In the meantime, the magic key combo is ctrl+space, as Harri said.
In the meantime, the magic key combo is ctrl+space, as Harri said.
127
Issues Help Desk / Re: Can not open manual
« on: November 09, 2012, 12:21:14 pm »
The F1/Help button is not implemented at this time. In the meantime, please instead use our wiki as the help file: http://enigma-dev.org/docs/wiki/
128
Announcements / Re: Commit Privileges
« on: October 25, 2012, 01:08:14 am »
That was his schedule last week, too, and he spent the free day making fun of the deplorable state of the project (and maybe being productive enough to pull vin's changes) :-p
129
Announcements / Re: Commit Privileges
« on: October 24, 2012, 06:19:27 pm »
Cool, you were able to stick that into LGM's settings panel without modifying LGM, so we must have done something right with the modularity. If you need any help with poking at the LGM-side of things, you know where to find me.
Harri: yeah, the texteditor has always been a pain. Before I got swamped, I was kinda working on making both JEdit and JoshEdit modules match in API so that you could swap them out easily (mainly so we could restore JEdit)
Harri: yeah, the texteditor has always been a pain. Before I got swamped, I was kinda working on making both JEdit and JoshEdit modules match in API so that you could swap them out easily (mainly so we could restore JEdit)
130
Proposals / Re: Collision shape options
« on: October 11, 2012, 03:43:10 pm »Quote
the sprite struct does not contain image data.Depends which sprite struct we're talking about.
backend/resources/sprite.h:36: SubImage *subImages;
backend/sub/SubImage.h:17: Image image;
backend/util/Image.h:16: char *data; //zlib compressed RGBA
131
Announcements / Re: Break In
« on: October 06, 2012, 08:21:20 pm »
Do we know which pages were phishing? Anybody who logged in with those pages during that time would also have their account compromised.
Also, for those of you concerned, please feel free to change your password.
Also, for those of you concerned, please feel free to change your password.
132
Issues Help Desk / Re: Help me run ENIGMA on Ubuntu
« on: September 26, 2012, 12:25:34 pm »
To update, do both a "git pull", followed by a "python install.py". The prior will update the ENIGMA compiler, and the latter will update the binary drivers for it (LateralGM and the Plugin). Since the binary drivers are updated less frequently, "git pull" is the more important one.
133
Proposals / Re: Arrays
« on: September 13, 2012, 03:47:01 pm »
Error/warn :-p
Seriously, though, what would the user expect [a,b] = 3; to do when a = b = 3 is just as easy to write.
Also, what happens with:
[a,b,c] = [1,2];
Seriously, though, what would the user expect [a,b] = 3; to do when a = b = 3 is just as easy to write.
Also, what happens with:
[a,b,c] = [1,2];
134
Proposals / Re: Resource group load/save functions
« on: September 13, 2012, 12:39:58 pm »
try_join looks like it's basically an is_alive check, so it might be more useful to just put it as that.
That said, all these advanced threading features should not be subset functions of a particular separate function API - they should have their own threading API.
That is to say, we shouldn't have _thread, _thread_join, and _thread_is_alive (or _thread_try_join) variants of particular functions, because then we'll quickly have function bloat over something that the user can just as easily wrap in a thread api, which will itself offer thread_join and thread_is_alive (or thread_try_join).
If we feel that threading resource group loading requests is going to be the de-facto standard, then simply have resource_group_load simply return a thread, and then maybe have a resource_group_load_and_wait variant. (to avoid confusion, maybe not even provide a r_g_l, and instead only provide r_g_l_thread and r_g_l_and_wait)
That said, all these advanced threading features should not be subset functions of a particular separate function API - they should have their own threading API.
That is to say, we shouldn't have _thread, _thread_join, and _thread_is_alive (or _thread_try_join) variants of particular functions, because then we'll quickly have function bloat over something that the user can just as easily wrap in a thread api, which will itself offer thread_join and thread_is_alive (or thread_try_join).
If we feel that threading resource group loading requests is going to be the de-facto standard, then simply have resource_group_load simply return a thread, and then maybe have a resource_group_load_and_wait variant. (to avoid confusion, maybe not even provide a r_g_l, and instead only provide r_g_l_thread and r_g_l_and_wait)
135
Proposals / Re: Resource group load/save functions
« on: September 13, 2012, 11:10:27 am »
Is loading/unloading recursive?