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 »
151
Announcements / Re: Parser Progress
« on: June 17, 2012, 02:46:50 am »
Hope you don't mind, I've added my own little update onto the end of the post.
152
General ENIGMA / Re: Linux and Windows Mobile Enigma
« on: June 15, 2012, 08:46:59 pm »
Also, ENIGMA does NOT use QT. We write our own platform windowing systems. On linux, we use Xlib (if you want widgets, we use GTK+), on Windows, we use Windows.h. On Mac, we use Cocoa. We also have windowing support for Android and iPhone. The system is very extensible to other platforms as well.
153
General ENIGMA / Re: LGM Image Editor
« on: June 09, 2012, 04:28:02 pm »
I have somewhat described the underlying features/flaws of each project. The rest is pretty much just visible things.
Pretty much all of the buttons (sans flood fill, for the moment) in JEIE are also reproduced in jimn's. Jimn's has a few more buttons that are implemented. He also has several buttons that are not implemented (text, selection), and icons for them (he used an icon set that is license compatible with JEIE and LGM, so JEIE could just as easily steal them). jimn's project also provides some tools with a widget to modify the behavior of the tool (e.g. brush width), which JEIE currently hasn't defined any widgets yet (although the framework supports them, and in a more modular fashion). jimn's also has alpha support and alpha blending support - something which JEIE still has some catching up to do with.
So basically, jimn's has more features - and those would need to be ported to JEIE. JEIE has a framework, which isn't really something you can port. He said he'd work on the memory thing (which is part of the framework).
The only other things that really stand out for the projects are the developers and the IDE. JEIE being developed in Eclipse by myself, with an extensive background in algorithms, but I hardly have the time to develop JEIE, so JEIE is inactive and will start falling behind. jimn appears to be actively developing his in Netbeans with the WYSIWYG, but he's doing a lot of learning as he goes, so you'll see some inefficient algorithms and the whole everything-in-1-class thing that I mentioned before.
A Netbeans project can be ported to Eclipse, but not vice versa if you plan to keep using the WYSIWYG. However, JEIE's framework makes adding components trivial, meaning you don't need a WYSIWYG at all.
Pretty much all of the buttons (sans flood fill, for the moment) in JEIE are also reproduced in jimn's. Jimn's has a few more buttons that are implemented. He also has several buttons that are not implemented (text, selection), and icons for them (he used an icon set that is license compatible with JEIE and LGM, so JEIE could just as easily steal them). jimn's project also provides some tools with a widget to modify the behavior of the tool (e.g. brush width), which JEIE currently hasn't defined any widgets yet (although the framework supports them, and in a more modular fashion). jimn's also has alpha support and alpha blending support - something which JEIE still has some catching up to do with.
So basically, jimn's has more features - and those would need to be ported to JEIE. JEIE has a framework, which isn't really something you can port. He said he'd work on the memory thing (which is part of the framework).
The only other things that really stand out for the projects are the developers and the IDE. JEIE being developed in Eclipse by myself, with an extensive background in algorithms, but I hardly have the time to develop JEIE, so JEIE is inactive and will start falling behind. jimn appears to be actively developing his in Netbeans with the WYSIWYG, but he's doing a lot of learning as he goes, so you'll see some inefficient algorithms and the whole everything-in-1-class thing that I mentioned before.
A Netbeans project can be ported to Eclipse, but not vice versa if you plan to keep using the WYSIWYG. However, JEIE's framework makes adding components trivial, meaning you don't need a WYSIWYG at all.
154
General ENIGMA / Re: LGM Image Editor
« on: June 09, 2012, 03:51:26 pm »
jimn346 and I have discussed this to my satisfaction, and he has my blessing to continue as he'd like, or integrate into JEIE.
However, it needs work. The project has a few insufficiencies that must be addressed (namely, it's a big memory hog) before it can be plugged into LGM. I also think people might be hesitant to develop for it since all of the code is contained in 1 java file of about 6000 LOC (and 1 more for handling Blurring).
As such, JEIE will continue to exist as a competitor, as I believe it has a much more solid framework to build off of.
However, it needs work. The project has a few insufficiencies that must be addressed (namely, it's a big memory hog) before it can be plugged into LGM. I also think people might be hesitant to develop for it since all of the code is contained in 1 java file of about 6000 LOC (and 1 more for handling Blurring).
As such, JEIE will continue to exist as a competitor, as I believe it has a much more solid framework to build off of.
155
General ENIGMA / Re: LGM Image Editor
« on: June 08, 2012, 03:20:07 pm »
I would like to speak with you in the IRC whenever you're around to get an idea of what direction you went with this and how this may pertain to/divert from the existing JEIE project.
I would also somewhat discourage using my blurring algorithm(s) from JEIE because I was not happy with them at all, but you may have found suitable workarounds to their insufficiencies, so we can discuss that as well.
If I find your project to my liking, I'll gladly deprecate JEIE in favor of yours and then help to implement it into LateralGM (probably just do it myself).
I would also somewhat discourage using my blurring algorithm(s) from JEIE because I was not happy with them at all, but you may have found suitable workarounds to their insufficiencies, so we can discuss that as well.
If I find your project to my liking, I'll gladly deprecate JEIE in favor of yours and then help to implement it into LateralGM (probably just do it myself).
156
Announcements / Re: Windows GIT patch
« on: May 23, 2012, 10:19:40 pm »
A discussion between Polygone and Harrikiri regarding Path implementation and troubles has been split into a new topic:
http://enigma-dev.org/forums/index.php?topic=971
Title: Path trouble
http://enigma-dev.org/forums/index.php?topic=971
Title: Path trouble
157
Issues Help Desk / Re: LGM standalone game not running!
« on: May 17, 2012, 10:39:40 pm »
I would recommend sticking with GM (or whatever else you're using) for the time being, then.
Enigma is still undergoing heavy development at this time.
It can't hurt too much to install Enigma (via the Git process) and try it out, but I would *not* depend on Enigma. Many functions are still unimplemented (although this list is rapidly shrinking).
We have no web port planned for the very near future - the closest we have is the ability to embed executables in the browser using some third party exe embedder (Anyone know which one can do it? Is it Gmbed?)
Enigma is still undergoing heavy development at this time.
It can't hurt too much to install Enigma (via the Git process) and try it out, but I would *not* depend on Enigma. Many functions are still unimplemented (although this list is rapidly shrinking).
We have no web port planned for the very near future - the closest we have is the ability to embed executables in the browser using some third party exe embedder (Anyone know which one can do it? Is it Gmbed?)
158
Issues Help Desk / Re: LGM standalone game not running!
« on: May 17, 2012, 03:08:01 pm »
Let's focus on the example games, since you seem to be having trouble with them.
Polygone confirmed that the Maze game works fine for him with the Git install.
Which installation method did you use? At this time, we have 2 prominent install methods for Windows:
* The Svn Install, which has been working for the longest, but is getting sorely outdated
* The Git Install, which is brand new, since Josh just released the patch to get that working on Windows just a couple days ago. We're still working on formalizing this method, getting the wiki updated, etc.
If you have the Svn install (e.g. downloaded the zip named blah_blah_SVN.zip), we'd like to encourage you to try out the Git install at this time: http://enigma-dev.org/docs/Wiki/Install:Git
Hopefully this will correct your problem.
Polygone confirmed that the Maze game works fine for him with the Git install.
Which installation method did you use? At this time, we have 2 prominent install methods for Windows:
* The Svn Install, which has been working for the longest, but is getting sorely outdated
* The Git Install, which is brand new, since Josh just released the patch to get that working on Windows just a couple days ago. We're still working on formalizing this method, getting the wiki updated, etc.
If you have the Svn install (e.g. downloaded the zip named blah_blah_SVN.zip), we'd like to encourage you to try out the Git install at this time: http://enigma-dev.org/docs/Wiki/Install:Git
Hopefully this will correct your problem.
159
Issues Help Desk / Re: LGM standalone game not running!
« on: May 17, 2012, 12:26:59 pm »
Not necessarily.
1: Java is not the only language that you can make browser-playable games in. There's also HTML5.
2: You can always embed your game, just like with Game Maker.
1: Java is not the only language that you can make browser-playable games in. There's also HTML5.
2: You can always embed your game, just like with Game Maker.
160
Issues Help Desk / Re: LGM standalone game not running!
« on: May 17, 2012, 12:10:54 pm »
Since I'm the Exception person here, I suppose I'll just poke in to confirm what's already been said.
The error message of the exception says 'Unexpected end of file reached at filepos: 208', which means your file appears to be 208 bytes - way too small for a game. It got corrupted somehow, and the old MP3s trick isn't the culprit (first, LGM can load games with giant resources just fine. It's GM that complains. Second, giant resource games aren't actually corrupted. Third, even if they did, the corruption would be much further along than 208 bytes).
As for the sample games not working, unfortunately I'm not in a good position to help much more at this point because enigma doesn't work at all on my OS - so it may be broken, or it may not be - I can't attempt to reproduce your problem at this time. Maybe someone else here can try out the games you mentioned and see if they have the same issue.
Also, you mentioned converting your games. Be aware that at this time there are no plans to add conversion to Java. Some older projects (G-Java, G-Creator, Dolphin) were aiming for that, but they dissolved or have not been heard from again. Currently, we're aiming to do 1 thing, and do it well: C++.
Once we get that working, then maybe later on down the road we can switch focus to other languages.
The error message of the exception says 'Unexpected end of file reached at filepos: 208', which means your file appears to be 208 bytes - way too small for a game. It got corrupted somehow, and the old MP3s trick isn't the culprit (first, LGM can load games with giant resources just fine. It's GM that complains. Second, giant resource games aren't actually corrupted. Third, even if they did, the corruption would be much further along than 208 bytes).
As for the sample games not working, unfortunately I'm not in a good position to help much more at this point because enigma doesn't work at all on my OS - so it may be broken, or it may not be - I can't attempt to reproduce your problem at this time. Maybe someone else here can try out the games you mentioned and see if they have the same issue.
Also, you mentioned converting your games. Be aware that at this time there are no plans to add conversion to Java. Some older projects (G-Java, G-Creator, Dolphin) were aiming for that, but they dissolved or have not been heard from again. Currently, we're aiming to do 1 thing, and do it well: C++.
Once we get that working, then maybe later on down the road we can switch focus to other languages.
161
Issues Help Desk / Re: LGM standalone game not running!
« on: May 17, 2012, 10:50:42 am »
Jordan, have you tried one of the sample games provided throughout our website? I believe there's even one included on the Install page. These are games that are known to work on working ENIGMA installs - so if that doesn't work for you, it means we broke something. Custom built games can kind of be a hit or a miss - maybe you used some unsupported function, or maybe you used some functions in an order that we don't support yet, or something like that.
162
Proposals / Re: Options Panel for LGM
« on: May 16, 2012, 05:23:25 pm »
I agree with not overkilling the UI, the combobox certainly sounds like another option - with "Custom" as one of the options that automatically selects if you change anything. The mouse reasoning is silly - it's not like the user's going to be changing the profile frequently.
163
Proposals / Re: Options Panel for LGM
« on: May 16, 2012, 11:03:51 am »Quote
When you toggle a checkboxWhen you toggle a setting - I presume you meant. Using "checkbox" makes your sentence very confusing.
Initially I was just thinking of having a Button, instead of a checkbox.
The way you describe it, it sounds like a "Save Profile" and "Load Profile" button - if simplified to not traverse directories - would be a pretty good solution.
164
Announcements / Re: Windows GIT patch
« on: May 15, 2012, 09:45:56 pm »Quote
Wouldn't you need to check the global every redraw anyway? Like what Poly just did with GLEW_EXT_framebuffer_object.let's assume you have a function, bool canFBO() which takes 20 milliseconds to return - so it's a time-intensive operation.
Scenario 1: We use canFBO() everywhere we want to use FBO, so we know if we have to use an alternative method instead. Every single call is 20 milliseconds, and those add up. Your game will run a little sluggish.
Scenario 2: We store the return value of canFBO() in a global variable right up front. Start of game is delayed 20 milliseconds. Every time thereafter that we want to use FBO, we check our global variable, which takes nanoseconds. At the cost of 20 milliseconds up front, we have sped up the rest of our game (or, rather, prevented it from slowing down with all those checks).
So to answer your question, yes, we will have to keep checking the variable, but if canFBO() is a time-intensive operation, it's *much* more preferable to check the variable than to check the function.
However, as polygone pointed out, canFBO() is actually a trivial and non-time-intensive operation, so it doesn't matter if you use a global or the function.
165
Announcements / Re: Windows GIT patch
« on: May 15, 2012, 01:28:18 pm »Quote
Adding global will not change anything much as you still need to do the if check somewhereHowever, for a time-intensive operation, adding global will only need to perform the check once, rather than every time.