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.
107
Proposals / Proposed Central Documentation Format
« on: May 21, 2010, 04:53:44 pm »
Anyway, the gist of my thoughts is basically what I did with that SVG explaining tiers. Those who pay attention to elements of design may have noticed that some borders contained a somewhat-cheesy image in the upper-left corner. I would like for several key groups to have such.
Of those in the SVG was a clock. The clock signifies future implications and was purely aesthetic. Same for the question mark, which I would like to change later on. It signifies notes on philosophy. I want another symbol with some kind of yellow and green divided image that will signify a difference between GM and ENIGMA resulting from the system. This is where it gets important: It would be useful to have a method of indexing such, especially the differences, possibly the philosophy and possibly notes on future implications. That way, if anyone pulls an Ism and finds what seems to be some minute difference between ENIGMA and GM, They can check it against that list. Otherwise, they can file a bug report.
Problem is, that requires indexing via something akin to SQL. Perhaps the format could be a simple to parse BBCode-like tagset that represents a div with a particular image in the corner. For example,
[future]This system implies that down the road...[/future] [philosophy]The system was chosen because precedence was given to the idea of...[/philosophy]
[bannergraphic]http://enigma-dev.org/docs/link_graphic.svg[/bannergraphic]
[simple=2]This graphic illustrates the system at work assuming that the conditions are such to allow for...[/simple]
Notice a few things. There are no
s. I was thinking the system would be best suited to a well-padded table. Tag [bannergraphic] ends the current row, if there is one, allocating a new row especially for a centered graphic. The example shows SVG. This is negotiable, and may in fact be best left out, though most browsers are capable of displaying them considering that the format is open.
Also, the =2 following the simple. This is to imply that the span/td should span two columns. Otherwise the parser should assume overflow should be done vertically.
This is my proposal for a good HTML-based help format. I wouldn't mind working with it, assuming Gary can whip me up a respectable inline editor, and I know he is beyond capable.
Of those in the SVG was a clock. The clock signifies future implications and was purely aesthetic. Same for the question mark, which I would like to change later on. It signifies notes on philosophy. I want another symbol with some kind of yellow and green divided image that will signify a difference between GM and ENIGMA resulting from the system. This is where it gets important: It would be useful to have a method of indexing such, especially the differences, possibly the philosophy and possibly notes on future implications. That way, if anyone pulls an Ism and finds what seems to be some minute difference between ENIGMA and GM, They can check it against that list. Otherwise, they can file a bug report.
Problem is, that requires indexing via something akin to SQL. Perhaps the format could be a simple to parse BBCode-like tagset that represents a div with a particular image in the corner. For example,
[future]This system implies that down the road...[/future] [philosophy]The system was chosen because precedence was given to the idea of...[/philosophy]
[bannergraphic]http://enigma-dev.org/docs/link_graphic.svg[/bannergraphic]
[simple=2]This graphic illustrates the system at work assuming that the conditions are such to allow for...[/simple]
Notice a few things. There are no
s. I was thinking the system would be best suited to a well-padded table. Tag [bannergraphic] ends the current row, if there is one, allocating a new row especially for a centered graphic. The example shows SVG. This is negotiable, and may in fact be best left out, though most browsers are capable of displaying them considering that the format is open.
Also, the =2 following the simple. This is to imply that the span/td should span two columns. Otherwise the parser should assume overflow should be done vertically.
This is my proposal for a good HTML-based help format. I wouldn't mind working with it, assuming Gary can whip me up a respectable inline editor, and I know he is beyond capable.
108
Announcements / The Saga Continues
« on: May 16, 2010, 09:54:29 pm »
I'm pleased to inform that Makefiles now work, themselves, exactly as I intended them to. I had some trouble getting them to work on Windows, but now it's looking good. I've renamed some of them to use the "proper" case. The rest will follow in their own time.
I have two computers in front of me. One is about seven years old and runs a single core, 2.9 GHz. It compiles and runs in roughly 5 seconds.
My other is a much more recent lap top. Roughly a year old, dual core, 2.88. It compiles and runs the game in about 2 seconds by my stopwatch (2.07, actually, thanks for asking).
Anyway, those are basically pointless statistics. I encourage users to check out 224 and test it for themselves. I'll be doing a couple important things next, in this order:
1. Add sprites to the exe again.
1.5. Deal with the series of adversities resulting from that move on both operating systems.
2. Replace var with my stagnating recode.
3. Replace instance system with my semi-documented second version. This will implement depth and hopefully heredity.
4. Reincorporate macros and scoping into the syntax check, as well as replacing operators := and <> (begin and end will be macros).
4.5. With the new instance system in, incorporate event behaviors, default events and event prefixes (such as alarm behaviors, default draw event [draw_sprite] and force calculations at the beginning of step).
5. Backgrounds from sprites.
6. ? ? ? ?
7. Profit? Just release? I don't know. Maybe I'll move on to sounds and leave the project in the SVN, maybe I'll make the testing phase more public by bringing the project out of the SVN.
There's not been a better time to check out the SVN than now (Yes, it's only getting better from here, I hope). If you do not know how, refer to old topics or ask here.
Please report all problems, however minor, preferably here until we've a bugtracker.
Furthermore, I should mention that I believe the new instance system will further lessen compile time. A schematic will be posted when one is available.
One last thing. If anyone who has checked out previously on Windows has trouble compiling, I recommend deleting your old makefiles and checking out the new ones. Windows and its SVN clients are... odd about that. To say the least. I suppose this goes for Linux fans, too, but it's unnecessary as make never tries to execute comment lines on Linux.
I have two computers in front of me. One is about seven years old and runs a single core, 2.9 GHz. It compiles and runs in roughly 5 seconds.
My other is a much more recent lap top. Roughly a year old, dual core, 2.88. It compiles and runs the game in about 2 seconds by my stopwatch (2.07, actually, thanks for asking).
Anyway, those are basically pointless statistics. I encourage users to check out 224 and test it for themselves. I'll be doing a couple important things next, in this order:
1. Add sprites to the exe again.
1.5. Deal with the series of adversities resulting from that move on both operating systems.
2. Replace var with my stagnating recode.
3. Replace instance system with my semi-documented second version. This will implement depth and hopefully heredity.
4. Reincorporate macros and scoping into the syntax check, as well as replacing operators := and <> (begin and end will be macros).
4.5. With the new instance system in, incorporate event behaviors, default events and event prefixes (such as alarm behaviors, default draw event [draw_sprite] and force calculations at the beginning of step).
5. Backgrounds from sprites.
6. ? ? ? ?
7. Profit? Just release? I don't know. Maybe I'll move on to sounds and leave the project in the SVN, maybe I'll make the testing phase more public by bringing the project out of the SVN.
There's not been a better time to check out the SVN than now (Yes, it's only getting better from here, I hope). If you do not know how, refer to old topics or ask here.
Please report all problems, however minor, preferably here until we've a bugtracker.
Furthermore, I should mention that I believe the new instance system will further lessen compile time. A schematic will be posted when one is available.
One last thing. If anyone who has checked out previously on Windows has trouble compiling, I recommend deleting your old makefiles and checking out the new ones. Windows and its SVN clients are... odd about that. To say the least. I suppose this goes for Linux fans, too, but it's unnecessary as make never tries to execute comment lines on Linux.
109
Proposals / LGM-ENIGMA options panel.
« on: May 16, 2010, 08:04:21 pm »
This is a tentative panel that will swell and shrink as I make up my mind on things.
However, this list can probably be inserted into documentation of some sort when it is settled.
Presently, these are the settings:
Inherit strings from:
Basically, this is where we will be inheriting the behavior of strings. ENIGMA introduces a new behavior in that show_message(chr(numbersignOrdinal)) will show "#", not a newline. Meaning that # is parsed as \n is in C, instead of handled special by every function that encounters it. This should cause little to no problem. As in, minor irritation in a very small minority of games.
Inherit ++/-- from:
In GML, ++ and -- are both the same as +. In C, they increment/decrement. This determines which it will do in the current game.
Treat Literals as:
Closing brace of struct:
As the most commonly missed semicolon, it was decided that it should be assumed to be there. This setting can toggle that off.
These are implemented, but should be reconsidered/removed:
Represent instances as:
I have yet to discover how well this will work with the room system's method of instance representation and yet to determine how to deal with any related changes that may be required as a result.
Store instances as:
"List" at least has become unnecessary due to my new instances system which has not yet been documented here nor implemented. Basically, it's because I'm storing things in multiple ways, list being one of them. I can still offer a choice between Map and Array for the other.
This should be added:
Inherit operator= from:
This needs implemented because I, for one, am offended by the behavior of a = b = c; in GML. It should set a and b both to c, not set a to the boolean value of b == c. So it'd be good to have an option for it.
Other potentially useful options that would have to be forms include these:
Default variable type: Defaults to var in all cases.
Default template parameter type: Thinking it should default to variant.
Questions I anticipate:
Won't this mean that you'll have to change things constantly?
No, these settings are local to each game. When Ism's versioning modifications are complete, this is Wwhat it will look like:
Loading a GM6/GMK will set all options to the left (unless Ism adds a mechanism to change this default GM import behavior).
Loading an EGM (which has yet to be genuinely forged, sadly) will load any previously saved settings.
Won't these mean huge recompile times?
For most of these, not if the tier system is implemented correctly for the lower systems and a unique system is implemented for higher systems. For the choice between array and map for instance storage, the system may or may not be geared to allow branched inclusion between the two. Don't count on it, though, as games using Array/Vector will probably be few anyway due to performance issues on create.
However, this list can probably be inserted into documentation of some sort when it is settled.
Presently, these are the settings:
Inherit strings from:
Basically, this is where we will be inheriting the behavior of strings. ENIGMA introduces a new behavior in that show_message(chr(numbersignOrdinal)) will show "#", not a newline. Meaning that # is parsed as \n is in C, instead of handled special by every function that encounters it. This should cause little to no problem. As in, minor irritation in a very small minority of games.
Inherit ++/-- from:
In GML, ++ and -- are both the same as +. In C, they increment/decrement. This determines which it will do in the current game.
Treat Literals as:
Closing brace of struct:
As the most commonly missed semicolon, it was decided that it should be assumed to be there. This setting can toggle that off.
These are implemented, but should be reconsidered/removed:
Represent instances as:
I have yet to discover how well this will work with the room system's method of instance representation and yet to determine how to deal with any related changes that may be required as a result.
Store instances as:
"List" at least has become unnecessary due to my new instances system which has not yet been documented here nor implemented. Basically, it's because I'm storing things in multiple ways, list being one of them. I can still offer a choice between Map and Array for the other.
This should be added:
Inherit operator= from:
This needs implemented because I, for one, am offended by the behavior of a = b = c; in GML. It should set a and b both to c, not set a to the boolean value of b == c. So it'd be good to have an option for it.
Other potentially useful options that would have to be forms include these:
Default variable type: Defaults to var in all cases.
Default template parameter type: Thinking it should default to variant.
Questions I anticipate:
Won't this mean that you'll have to change things constantly?
No, these settings are local to each game. When Ism's versioning modifications are complete, this is Wwhat it will look like:
Loading a GM6/GMK will set all options to the left (unless Ism adds a mechanism to change this default GM import behavior).
Loading an EGM (which has yet to be genuinely forged, sadly) will load any previously saved settings.
Won't these mean huge recompile times?
For most of these, not if the tier system is implemented correctly for the lower systems and a unique system is implemented for higher systems. For the choice between array and map for instance storage, the system may or may not be geared to allow branched inclusion between the two. Don't count on it, though, as games using Array/Vector will probably be few anyway due to performance issues on create.
110
Announcements / Fixed those Makefiles
« on: May 12, 2010, 08:00:05 am »
Good news everyone. I got the makefiles not to recompile all the time. I've not yet committed my changes though; be patient. I want to make sure all the changes I've made to the syntax checker and parser hold up during some field testing, and there's some code that needs moved around because it's being called too often.
Anyway, I'm not sure I can enumerate all the changes between my next revision (expect it tonight) and my last; that's why we have Diff.
The IRC has relieved me of the things I usually keep in a list to say when I make a newspost, especially with freezway asking how makefiles are coming every twenty minutes. Freezway, the makefiles work, but you can't have them. So there.
I may as well share concerns as well as success. I decided to use makefiles, despite them being an ancient art that's a huge pain to get working, because I wanted individual systems to be responsible for their own rules of building. This would be especially helpful, I thought, when we did the Wii port, which is necessarily Make-based. Problem is, I'm not sure what changes would need made to the makefile (particularly the ones under SHELL/ and SHELL/Universal_System/) to enable the modified Make to compile it correctly. I will need to thoroughly inspect the Wii-written makefiles for things that need set.
The most glaringly obvious of these is that $(DEVKITPPC) needs set, and that it includes a file called wii_rules from that directory. This leaves a number of questions that I can't yet answer with certainty. Namely, do I want to make it so that every system relies on a file called $(COMPILER_DATA)/$(PLATFORMNAME)_rules? Do I want to just include makefiles/makefile.$(PLATFORMNAME)?
It seems the latter would be the simplest as well as the most easily extended since as many files can be dumped into that folder as the OS allows, and the makefile will include any of them LGM/ENIGMA request by name or fragment of name (wii, pc, etc). It is what I will likely be going with unless someone has a better idea.
That leaves one additional problem that needs dealt with for a number of reasons. How do we incorporate multiple compilers? Currently, ENIGMA frantically searches for c++ and g++ at load time. If it doesn't find them, it errors to Ism, who asks the user. Either way, it leaves knowing where gcc and make/mingw32-make are located. That location name can be made into a map, certainly. But, where do we store compiler information? A new folder, ENIGMAsystem/compilers/? A new text file, ENIGMAsystem/compilers? The former would be more desirable so that, should compilers be pluginized (and this is thinking way ahead), plugins aren't fighting for permissions and last word in one text file, and aren't iterating it on and off for their input. It would just rely--as the entire remainder of the system would, really--on no two compilers sharing a name.
Perhaps all that belongs in Proposals anyway, I guess I just needed something to put in this newspost. Maybe I'll post it there later.
Anyway, real work to do now.
Cheers.
Anyway, I'm not sure I can enumerate all the changes between my next revision (expect it tonight) and my last; that's why we have Diff.
The IRC has relieved me of the things I usually keep in a list to say when I make a newspost, especially with freezway asking how makefiles are coming every twenty minutes. Freezway, the makefiles work, but you can't have them. So there.
I may as well share concerns as well as success. I decided to use makefiles, despite them being an ancient art that's a huge pain to get working, because I wanted individual systems to be responsible for their own rules of building. This would be especially helpful, I thought, when we did the Wii port, which is necessarily Make-based. Problem is, I'm not sure what changes would need made to the makefile (particularly the ones under SHELL/ and SHELL/Universal_System/) to enable the modified Make to compile it correctly. I will need to thoroughly inspect the Wii-written makefiles for things that need set.
The most glaringly obvious of these is that $(DEVKITPPC) needs set, and that it includes a file called wii_rules from that directory. This leaves a number of questions that I can't yet answer with certainty. Namely, do I want to make it so that every system relies on a file called $(COMPILER_DATA)/$(PLATFORMNAME)_rules? Do I want to just include makefiles/makefile.$(PLATFORMNAME)?
It seems the latter would be the simplest as well as the most easily extended since as many files can be dumped into that folder as the OS allows, and the makefile will include any of them LGM/ENIGMA request by name or fragment of name (wii, pc, etc). It is what I will likely be going with unless someone has a better idea.
That leaves one additional problem that needs dealt with for a number of reasons. How do we incorporate multiple compilers? Currently, ENIGMA frantically searches for c++ and g++ at load time. If it doesn't find them, it errors to Ism, who asks the user. Either way, it leaves knowing where gcc and make/mingw32-make are located. That location name can be made into a map, certainly. But, where do we store compiler information? A new folder, ENIGMAsystem/compilers/? A new text file, ENIGMAsystem/compilers? The former would be more desirable so that, should compilers be pluginized (and this is thinking way ahead), plugins aren't fighting for permissions and last word in one text file, and aren't iterating it on and off for their input. It would just rely--as the entire remainder of the system would, really--on no two compilers sharing a name.
Perhaps all that belongs in Proposals anyway, I guess I just needed something to put in this newspost. Maybe I'll post it there later.
Anyway, real work to do now.
Cheers.
111
Proposals / Tiering vs Components
« on: May 08, 2010, 12:37:01 pm »
It looks like it's time once again for a poll.
Before voting, give Miky / Rusky a chance to present their idea of a Component system, as applicable to ENIGMA.
If you have a separate proposal, post it in the same format as I am about to post mine. This format should include the following:
- Code for an object called object0 containing a local "my_local"
----- This should include ALL code required to include necessary locals, particularly those needed throughout the rest of this demonstration
- Code for a simple collision function, check_collision(int id), returning bool, utilizing these hypothetical functions:
----- get_object_by_id(int), returning whatever the system requires (probably a pointer)
----- check_rotated_rectangle(x,y,bbox_left,bbox_right,bbox_top,bbox_bottom,image_angle); returning bool
- A create event code that shows message "Hello, world! I am at (<x>,<y>)", as it will look when compiled.
My code will have the official names in it, except where a substitute has been given above explicitly. It doesn't really matter what return types are if not specified.
DO NOT vote before a similar description is available for the Component system.
Moreover, I'd say requesting additional code on the behalf of either/any party is fair game.
Before voting, give Miky / Rusky a chance to present their idea of a Component system, as applicable to ENIGMA.
If you have a separate proposal, post it in the same format as I am about to post mine. This format should include the following:
- Code for an object called object0 containing a local "my_local"
----- This should include ALL code required to include necessary locals, particularly those needed throughout the rest of this demonstration
- Code for a simple collision function, check_collision(int id), returning bool, utilizing these hypothetical functions:
----- get_object_by_id(int), returning whatever the system requires (probably a pointer)
----- check_rotated_rectangle(x,y,bbox_left,bbox_right,bbox_top,bbox_bottom,image_angle); returning bool
- A create event code that shows message "Hello, world! I am at (<x>,<y>)", as it will look when compiled.
My code will have the official names in it, except where a substitute has been given above explicitly. It doesn't really matter what return types are if not specified.
DO NOT vote before a similar description is available for the Component system.
Moreover, I'd say requesting additional code on the behalf of either/any party is fair game.
112
Proposals / Operators .., =, :=
« on: May 05, 2010, 07:40:42 pm »
At present, only operator= is implemented, of the above. I was thinking about implementing a couple neat tricks.
1) Copy-on-write, as mentioned earlier. The ability to set variables to arrays simply with operator=. Only problem; writing will actually be slow, unlike if operator= simply copied the first element as it does in GM.
2) Array sub-arrays via operator.., which does not exist in C++. Basically, when you say varname[2..3], you get the contents of varname[2] and varname[3]. This could be handled by replacing [x..y] with .subArray(x,y). This requires only that the class being accessed has subArray defined, so user-implemented classes could easily provide the same functionality. (As an alternative, an overloadable function could be used, since C++ isn't so easily modified as, say, JavaScript.
3) Referencing vs. Hard copying; should subArray just copy the contents over, as subString does?
So, I was thinking about hijacking operator:=, which does not exist in C++. This could be used to indicate that data should be hard copied instead of perhaps just turn copying the entire array on via a setting. My original idea was to use := to indicate a hard copy, but such would be difficult without some class tinkering.
Yadda yadda, definitely considering implementing [..] as a wrapper to subArray, not sure what subArray should reference vs what it should copy. Fin.
1) Copy-on-write, as mentioned earlier. The ability to set variables to arrays simply with operator=. Only problem; writing will actually be slow, unlike if operator= simply copied the first element as it does in GM.
2) Array sub-arrays via operator.., which does not exist in C++. Basically, when you say varname[2..3], you get the contents of varname[2] and varname[3]. This could be handled by replacing [x..y] with .subArray(x,y). This requires only that the class being accessed has subArray defined, so user-implemented classes could easily provide the same functionality. (As an alternative, an overloadable function could be used, since C++ isn't so easily modified as, say, JavaScript.
3) Referencing vs. Hard copying; should subArray just copy the contents over, as subString does?
So, I was thinking about hijacking operator:=, which does not exist in C++. This could be used to indicate that data should be hard copied instead of perhaps just turn copying the entire array on via a setting. My original idea was to use := to indicate a hard copy, but such would be difficult without some class tinkering.
Yadda yadda, definitely considering implementing [..] as a wrapper to subArray, not sure what subArray should reference vs what it should copy. Fin.
113
Proposals / Custom Widgets
« on: May 04, 2010, 09:26:23 pm »
If ENIGMA had its own, draw_*()-drawn widgets library, made of primitives, it would, for one thing, make some users' lives easier (Remember Roach's GMWidgets? I think that was his. It's been a while). More importantly, it would make build mode cross platform automatically. For this to work, ENIGMA requires a well-working draw_text(). Ism and I, as usual, need to talk about that...
I guess I'd write the library, though it's not a difficult task, really. Just tedious-ish, especially if it is to support any platform-specific features... I guess widgets_get_selected_text() could return last selected in-window text on Windows, and do what it's told on Linux, and that's the main difference between the two platforms. That and scroll bars.
Ism, when you see this; does Java have the ability to render a glyph to an image? Otherwise, I need to include some cross-platform glyph renderer in the compiler...
I guess I'd write the library, though it's not a difficult task, really. Just tedious-ish, especially if it is to support any platform-specific features... I guess widgets_get_selected_text() could return last selected in-window text on Windows, and do what it's told on Linux, and that's the main difference between the two platforms. That and scroll bars.
Ism, when you see this; does Java have the ability to render a glyph to an image? Otherwise, I need to include some cross-platform glyph renderer in the compiler...
114
Proposals / On Settings and Dependencies
« on: May 04, 2010, 09:22:18 pm »
It may behoove me to write a makefile generator based off of my C parser; specifically, its preprocessor (rather, the segment of code that preprocesses, since a distinct pass is not made for the matter). The modification would be relatively simple; it seems I can just add anything #include""ed (note the "", not <>) to the list of dependencies for a file. Automake is another option. A uniform or empty dependency list is a third and final ugly option that would yield pain.
Either way, the proposal is this: Along with a config file to identify the system, each system should have a settings file outlined either in the config file or a settingsOutline file. Basically, the former will read
And the latter will contain
From that, LGM will generate a checkbox (boolean) with the English string above. Other options than boolean can be discussed later; XML would be a pain but is a consideration for combo boxes, etc.
From the same, ENIGMA will check a settings header, settings.h, to make sure it matches up (yes, perfectly; it should be entirely generated) with the data from LGM. If it doesn't, it will be opened for write and reconstructed.
The reason is quite simple. Make will not rebuild a file as long as nothing it includes has been modified. This means that ENIGMA shouldn't touch the settings file in write mode if it doesn't intend to change something in particular, or stuff will rebuild all the time (This is not what is causing the current problems, as this idea has just been thought up).
Ism's is basically the only opinion that counts here. This means work for both of us, but will greatly increase extensibility and avoid hard-coded options. Problem for Ism is calculated the size of the window and placement of the options; a simple process in Win32 may not be easy with Java.
So...
Either way, the proposal is this: Along with a config file to identify the system, each system should have a settings file outlined either in the config file or a settingsOutline file. Basically, the former will read
Code: [Select]
#define SETTING_PRIMITIVES_REQUIRE_VBO false
#define SETTING_PRIMITIVES_REQUIRE_FBO falseAnd the latter will contain
Code: [Select]
Settings:
option "Require VBO Extension" defines "SETTING_PRIMITIVES_REQUIRE_VBO" as boolean defaults to "false"
option "Require FBO Extension" defines "SETTING_PRIMITIVES_REQUIRE_FBO" as boolean defaults to "false"From that, LGM will generate a checkbox (boolean) with the English string above. Other options than boolean can be discussed later; XML would be a pain but is a consideration for combo boxes, etc.
From the same, ENIGMA will check a settings header, settings.h, to make sure it matches up (yes, perfectly; it should be entirely generated) with the data from LGM. If it doesn't, it will be opened for write and reconstructed.
The reason is quite simple. Make will not rebuild a file as long as nothing it includes has been modified. This means that ENIGMA shouldn't touch the settings file in write mode if it doesn't intend to change something in particular, or stuff will rebuild all the time (This is not what is causing the current problems, as this idea has just been thought up).
Ism's is basically the only opinion that counts here. This means work for both of us, but will greatly increase extensibility and avoid hard-coded options. Problem for Ism is calculated the size of the window and placement of the options; a simple process in Win32 may not be easy with Java.
So...
115
Announcements / Finals
« on: May 04, 2010, 07:59:26 am »
Yes, yes, I know ENIGMA has problems. Stop checking out before Ism posts a compatible revision number (which you can look up at any time on the IRC... Maybe I can have a2h keep one here and IsmBot can check it as well).
ANYWAY. I am in the belly of finals week. Right now, I can't whimsically fix things. Ism recommended I update to Lucid. To do that, I'd have to go through Karmic. Well, now my box won't boot. So even when finals week is over (Thursday I either sink or float), I can't immediately fix ENIGMA as my box is dead. (It can heal while I work from a lap top, though).
- Hey, how are finals going so far?
Great, thanks for asking! (No, no one asked.)
So far, I am done with Computer Architecture. My professor may be the kindest on the planet, I'm thinking. I finished off with a 101% or so, which may be enough to help counter the 10% I'm about to be awarded in Political Science by a professor I can only describe as a typical politician. There's a sort of metaphysical wind blowing between the two buildings housing the aforementioned professors. If that sentence doesn't make sense to you, go study how wind and convection work and get back to me later.
And speaking of metaphysical whatever, today (in seven hours as of the posting of this message) I give a lecture (for 5-15 minutes) on Xenu. In front of 300 people or more.If I don't edit this by 9:00 that night, assume that I have either been shot on the stage or suffered some sort of conniption.
I also turn in a fifteen page paper at that time, which I will spend the rest of the meantime proofing.
Thank you for your ETERNAL PATIENCE and UNFLINCHING UNDERSTANDING coupled with a COMPLETE LACK of NAGGING. I GREATLY APPRECIATE IT.
I will see you all ASAP.
And no, I can't commit changes from here.
The presentation went great, except that, as stated below, I was shot and killed. Shame, really. I may continue to work on ENIGMA as a ghost if conditions permit.
ANYWAY. I am in the belly of finals week. Right now, I can't whimsically fix things. Ism recommended I update to Lucid. To do that, I'd have to go through Karmic. Well, now my box won't boot. So even when finals week is over (Thursday I either sink or float), I can't immediately fix ENIGMA as my box is dead. (It can heal while I work from a lap top, though).
- Hey, how are finals going so far?
Great, thanks for asking! (No, no one asked.)
So far, I am done with Computer Architecture. My professor may be the kindest on the planet, I'm thinking. I finished off with a 101% or so, which may be enough to help counter the 10% I'm about to be awarded in Political Science by a professor I can only describe as a typical politician. There's a sort of metaphysical wind blowing between the two buildings housing the aforementioned professors. If that sentence doesn't make sense to you, go study how wind and convection work and get back to me later.
And speaking of metaphysical whatever, today (in seven hours as of the posting of this message) I give a lecture (for 5-15 minutes) on Xenu. In front of 300 people or more.
I also turn in a fifteen page paper at that time, which I will spend the rest of the meantime proofing.
Thank you for your ETERNAL PATIENCE and UNFLINCHING UNDERSTANDING coupled with a COMPLETE LACK of NAGGING. I GREATLY APPRECIATE IT.
I will see you all ASAP.
And no, I can't commit changes from here.
The presentation went great, except that, as stated below, I was shot and killed. Shame, really. I may continue to work on ENIGMA as a ghost if conditions permit.
116
Proposals / Adding systems
« on: April 25, 2010, 10:54:18 pm »
I'm too tired to elaborate on this now, and am posting here mostly for Ism.
Key directories for swappable systems and otherwise (All under ENIGMAsystem/SHELL/):
/Universal_System/ Contains things that should work on any OS (Cross platform and C standard wrappers and functions).
/Platforms/ Contains directories for each available windowing/OS-dependent system. (windows [TO BE RENAMED to win32], xlib, [SOON?]cocoa, [SOON]wii)
/Graphics_Systems/ Contains directories for any available drawing systems. (OpenGL,[SOME DAY]DirectX,[SOON]GX)
Something to fix: the cases don't match between Platforms and Graphics_Systems, which is annoying-ish.
Anyway, of the system-specific folders, I have it currently set up so that each has a makefile. Right now, all the makefiles are the same. That will soon change.
From the scope of each directory, ENIGMA of course calls the makefile. LGM does not need to even acknowledge said file's existence. What LGM and ENIGMA will both need, however, is a settings/config file. For now, the file has not been named; I was considering "info" for the name. This file will be a simple one, similar to LGM's *.properties files (perhaps "properties" is a good name for this file). It reads something like this:
Notice that Link- is always proceeded by the name of an element in `Platforms', each of which is the same as a directory name.
If need be, the Platforms property can apply as a special case to folders under Platforms/ (for cases such as, just for example, using xlib in both Linux and in Mac OS X). This will probably be unnecessary, but consider that part of the purpose of the file until such is actually needed. What may be needed is a special variable for those called `Compiler', so developers can specify (especially in cases such as the Wii) that a different version of make will need to be called. This can get really messy, really fast (such as when conflicting binaries are specified by the Path variable; one for MinGW because it make ENIGMA easy, and one for Devkit's GCC, because it makes calling that easy), and so will need proper attention down the road.
Until then, this is the plan.
Key directories for swappable systems and otherwise (All under ENIGMAsystem/SHELL/):
/Universal_System/ Contains things that should work on any OS (Cross platform and C standard wrappers and functions).
/Platforms/ Contains directories for each available windowing/OS-dependent system. (windows [TO BE RENAMED to win32], xlib, [SOON?]cocoa, [SOON]wii)
/Graphics_Systems/ Contains directories for any available drawing systems. (OpenGL,[SOME DAY]DirectX,[SOON]GX)
Something to fix: the cases don't match between Platforms and Graphics_Systems, which is annoying-ish.
Anyway, of the system-specific folders, I have it currently set up so that each has a makefile. Right now, all the makefiles are the same. That will soon change.
From the scope of each directory, ENIGMA of course calls the makefile. LGM does not need to even acknowledge said file's existence. What LGM and ENIGMA will both need, however, is a settings/config file. For now, the file has not been named; I was considering "info" for the name. This file will be a simple one, similar to LGM's *.properties files (perhaps "properties" is a good name for this file). It reads something like this:
Code: [Select]
Name="OpenGL"
Description="An open source graphics library."
Platforms="windows, xlib"
Link-windows="-lopengl32"
Link-xlib="-lGL"Notice that Link- is always proceeded by the name of an element in `Platforms', each of which is the same as a directory name.
If need be, the Platforms property can apply as a special case to folders under Platforms/ (for cases such as, just for example, using xlib in both Linux and in Mac OS X). This will probably be unnecessary, but consider that part of the purpose of the file until such is actually needed. What may be needed is a special variable for those called `Compiler', so developers can specify (especially in cases such as the Wii) that a different version of make will need to be called. This can get really messy, really fast (such as when conflicting binaries are specified by the Path variable; one for MinGW because it make ENIGMA easy, and one for Devkit's GCC, because it makes calling that easy), and so will need proper attention down the road.
Until then, this is the plan.
117
Announcements / Remember when I said...
« on: April 25, 2010, 10:34:02 pm »
...That I knew enough Make? Well, I Lied.
I've committed revision 200, which contains some very simple makefiles that do exactly what I wanted. Except one little tidbit: I forgot that I'd need to outline for Make what every file depends upon, or it would rebuild the entire project. Every. Single. Time. As in, exactly what I spent hours and hours avoiding happening.
So yes, if you were to check out ENIGMA right now and click Run, LGM wouldn't display a damn thing, but (at least on Linux; haven't tested on Windows) it will build and run your game. I have not added sprites to the output; making it compile fast gets precedence.
However, above that precedent comes my homework. This is going to be the busiest two weeks of my life, and I need to account for that. I graduate from high school soon, but am taking all college classes. Most of which are upper-level. And I have exams coming up very quickly. One is, as I've mentioned, a fifteen page report on Scientology. What I may have neglected to mention is that I will be highlighting this report in front of an estimated three hundred people. This is a new sort of WHAT THE... BUT HOW... RATHER, WHY? for me, as I'm sure you all can understand... Public speaking is easy when you know exactly what the hell it is you are talking about. I'm going to be up there explaining space planes and aliens and frozen souls to the mindless. ...Computer science final will be a take-home cakewalk. Political science final, on the other hand, will be my fourth grade in that class, and will make me suffer. I haven't exactly done superbly on any of that man's four other assignments, either. ...Calculus would be great if it wasn't an AP high school course. I'm stuck, with one other, among a group of people that can't grasp the AB material, and I'll be taking the BC. Bother, a couple questions of the AB are harder than the BC anyway. My utter success on the BC portion hinges on my memorization of some dozen different series. Not exactly fun... And I've got a huge number of memory quizzes coming up, for which I've not studied...
Anyway; point is, I've got a lot on my plate for these next couple weeks, and will probably put ENIGMA on the back burner until I'm done. It won't be long.
So, to do: Optimize makefiles, replace var and instance system, fix up syntax check more, reinstall sprite system, move some code up a directory, replace timer on Linux, carry out some in-code to-dos.
Less immediate to-do: Modify sprite system into parallel background system, add tiles to room, add cross platform widget functions to enable build mode.
Further to-dos: Comment generated code for easy error indexing.
Distant to-dos: Hook up GDB for some really neat debugger kicks.
Until then, ciao.
I've committed revision 200, which contains some very simple makefiles that do exactly what I wanted. Except one little tidbit: I forgot that I'd need to outline for Make what every file depends upon, or it would rebuild the entire project. Every. Single. Time. As in, exactly what I spent hours and hours avoiding happening.
So yes, if you were to check out ENIGMA right now and click Run, LGM wouldn't display a damn thing, but (at least on Linux; haven't tested on Windows) it will build and run your game. I have not added sprites to the output; making it compile fast gets precedence.
However, above that precedent comes my homework. This is going to be the busiest two weeks of my life, and I need to account for that. I graduate from high school soon, but am taking all college classes. Most of which are upper-level. And I have exams coming up very quickly. One is, as I've mentioned, a fifteen page report on Scientology. What I may have neglected to mention is that I will be highlighting this report in front of an estimated three hundred people. This is a new sort of WHAT THE... BUT HOW... RATHER, WHY? for me, as I'm sure you all can understand... Public speaking is easy when you know exactly what the hell it is you are talking about. I'm going to be up there explaining space planes and aliens and frozen souls to the mindless. ...Computer science final will be a take-home cakewalk. Political science final, on the other hand, will be my fourth grade in that class, and will make me suffer. I haven't exactly done superbly on any of that man's four other assignments, either. ...Calculus would be great if it wasn't an AP high school course. I'm stuck, with one other, among a group of people that can't grasp the AB material, and I'll be taking the BC. Bother, a couple questions of the AB are harder than the BC anyway. My utter success on the BC portion hinges on my memorization of some dozen different series. Not exactly fun... And I've got a huge number of memory quizzes coming up, for which I've not studied...
Anyway; point is, I've got a lot on my plate for these next couple weeks, and will probably put ENIGMA on the back burner until I'm done. It won't be long.
So, to do: Optimize makefiles, replace var and instance system, fix up syntax check more, reinstall sprite system, move some code up a directory, replace timer on Linux, carry out some in-code to-dos.
Less immediate to-do: Modify sprite system into parallel background system, add tiles to room, add cross platform widget functions to enable build mode.
Further to-dos: Comment generated code for easy error indexing.
Distant to-dos: Hook up GDB for some really neat debugger kicks.
Until then, ciao.
118
Announcements / WHAT IS THIS I DON'T EVEN
« on: April 25, 2010, 12:06:21 pm »
Most of the progress reports have been going on at ENIGMA's composed-due-to-popular-opinion IRC channel on Freenode, #enigma-dev.
However, I figure it's a good idea to post what's been happening here as well.
Several bugs between platforms have been found, isolated, and corrected. ENIGMA now operates correctly on every Windows version and Linux distro on which it has been tested thus far. That includes mostly Ubuntu 9.xx and Windows XP, Vista, and 7. I could not test on 98 due to Code::Blocks not starting and me being too lazy to do anything about that.
Further, the fixed bugs include the following:
- Some string fixes (waiting for Ism's confirmation)
- x() being randomly defined as a function due to ## mishandling
- Freezing on XP if sprite load fails (which it always does for now)
- Variable overlap on systems where sizeof(size_t) != sizeof(unsigned)
- Failure to load function names for syntax check due to any of the above
- Many smaller things that just needed dealt with
Things that still need to be fixed:
- Minuscule memory leak during C parsing: I will run Valgrind when this is the most pressing of my concerns
Things that need done in general:
- Makeflies need written: I've learned enough make (it was surprisingly easy) and will do this next
- Sprites need added to exe after build: This couldn't be done without the makefile
- Pieces of R3 need salvaged now that the rest seems stable; these include script "linking" and build mode.
- Some pieces of individual graphics systems and window systems need moved to a parent file in ../ to simplify further implementation
- There are at least ten "TODO:" notes lying around the project.
I'm content to leave ENIGMA in the SVN for a while longer, but can probably put out the zip file for those who for some reason do not like operating on a direct line to updates.
Perhaps Ism can implement something to call a quick makefile in CompilerSource in order to allow for easy distribution... I will discuss that with her shortly.
However, I figure it's a good idea to post what's been happening here as well.
Several bugs between platforms have been found, isolated, and corrected. ENIGMA now operates correctly on every Windows version and Linux distro on which it has been tested thus far. That includes mostly Ubuntu 9.xx and Windows XP, Vista, and 7. I could not test on 98 due to Code::Blocks not starting and me being too lazy to do anything about that.
Further, the fixed bugs include the following:
- Some string fixes (waiting for Ism's confirmation)
- x() being randomly defined as a function due to ## mishandling
- Freezing on XP if sprite load fails (which it always does for now)
- Variable overlap on systems where sizeof(size_t) != sizeof(unsigned)
- Failure to load function names for syntax check due to any of the above
- Many smaller things that just needed dealt with
Things that still need to be fixed:
- Minuscule memory leak during C parsing: I will run Valgrind when this is the most pressing of my concerns
Things that need done in general:
- Makeflies need written: I've learned enough make (it was surprisingly easy) and will do this next
- Sprites need added to exe after build: This couldn't be done without the makefile
- Pieces of R3 need salvaged now that the rest seems stable; these include script "linking" and build mode.
- Some pieces of individual graphics systems and window systems need moved to a parent file in ../ to simplify further implementation
- There are at least ten "TODO:" notes lying around the project.
I'm content to leave ENIGMA in the SVN for a while longer, but can probably put out the zip file for those who for some reason do not like operating on a direct line to updates.
Perhaps Ism can implement something to call a quick makefile in CompilerSource in order to allow for easy distribution... I will discuss that with her shortly.
119
Announcements / Things that are broke
« on: April 15, 2010, 10:20:20 pm »
Those who have checked out the repository and began testing can continue reporting things here.
Presently, the project is torn between platforms, and is in what I would call a pretty pathetic state.
So far this phase, I cannot say "what works, works well." Most of the previous releases, not a lot worked, but what did was at least mostly reliable. This time, I couldn't even get it compiling on multiple platforms right away due to the insane amount of differences between each. Removing hard-coded features has proven to make the project very needy; not to mention LGM also seems to be in a worse state than last release.
What I'm coping/dealing with now:
- ENIGMA freezes/LGM segfaults on some 64bit machines (likely the ones such that sizeof(size_t) isn't matching up with another aliased size; segfault may be due to JNA's sizes not matching up with C++'s after all). Freezway has basically confirmed it is a problem with 64bit systems, as it worked fine on a 32bit version of the same OS.
- LGM's code editor is even worse on Linux; it misaligns text with cursor when keywords/comments are italicized. Not to mention on this box, Java is slower than all beans. Over all, I'm deeming it 'half a head of hair short of unusable;' but the latter half of my hair should be ripped out by tomorrow evening.
- Allocations on this box (Ubuntu) are ridiculously slow, and I have reason to believe that the frame timing mechanism is FUBAR. I will investigate thoroughly when some other problems are resolved. The reason I believe it is the allocation is that the framerate resumes full speed (if chopped) when an instance is destroyed before each new one is created (Meaning the program doesn't have to dig for more space before allocating some).
Does anyone know of a flag for fast, careless allocations?
If those don't seem like big problems to you, I want you to counsel me.
Other than that though, the project is great, thanks for asking. <_<"
Again, following this post are the instructions (still subject to change) for checking out and testing ENIGMA. You will have to follow these in order to test until I deem that the project is stable enough to distribute zipped (aka, when those above errors are corrected--at least ENIGMA's).
As for me, I have a lot of math homework. I will devote the first half of tomorrow to that, and then I will be done for a little until I have to write a fifteen-page essay on Scientology, which I must say I am not looking forward to.
Presently, the project is torn between platforms, and is in what I would call a pretty pathetic state.
So far this phase, I cannot say "what works, works well." Most of the previous releases, not a lot worked, but what did was at least mostly reliable. This time, I couldn't even get it compiling on multiple platforms right away due to the insane amount of differences between each. Removing hard-coded features has proven to make the project very needy; not to mention LGM also seems to be in a worse state than last release.
What I'm coping/dealing with now:
- ENIGMA freezes
- LGM's code editor is even worse on Linux; it misaligns text with cursor when keywords/comments are italicized. Not to mention on this box, Java is slower than all beans. Over all, I'm deeming it 'half a head of hair short of unusable;' but the latter half of my hair should be ripped out by tomorrow evening.
- Allocations on this box (Ubuntu) are ridiculously slow, and I have reason to believe that the frame timing mechanism is FUBAR. I will investigate thoroughly when some other problems are resolved. The reason I believe it is the allocation is that the framerate resumes full speed (if chopped) when an instance is destroyed before each new one is created (Meaning the program doesn't have to dig for more space before allocating some).
Does anyone know of a flag for fast, careless allocations?
If those don't seem like big problems to you, I want you to counsel me.
Other than that though, the project is great, thanks for asking. <_<"
Again, following this post are the instructions (still subject to change) for checking out and testing ENIGMA. You will have to follow these in order to test until I deem that the project is stable enough to distribute zipped (aka, when those above errors are corrected--at least ENIGMA's).
As for me, I have a lot of math homework. I will devote the first half of tomorrow to that, and then I will be done for a little until I have to write a fifteen-page essay on Scientology, which I must say I am not looking forward to.
120
Announcements / Anaphase
« on: April 02, 2010, 11:50:10 pm »
If I release it now, it'll be missing some things I think can be in not long into tomorrow. One of those is Linux support, which I don't want to throw out a release without ensuring: Number one, Linux has proven to be much more strict about what is used and included, and number two, wouldn't really be fair to freezeway, now, would it?
Also, it seems likely that given just a little more time, we can have the collision system hooked up and iterating. Luda has rotated rectangles basically good to go; he can develop the rest of the system during the test phase, but the framework would be nice to have laid out.
As for the aforementioned Linux progress, we can't actually compile it on Linux at present due to some case labels skipping initializations, which Windows didn't even notice for some reason...
I'm quite tired. A lot of work went into the engine just today, but there's no sweeter payoff than seeing the system working again. It's a beautiful sort of thing.
I imagine everyone will understand the decision to prolong the release again; one of my bigger fears is immediate mediocrity. (Did I mention the syntax check button once again doesn't do anything? It spent most of R3 like that... I won't let it for R4).
This doesn't change the amazingly close proximity of the test. Besides, I had to squeeze anaphase in here somewhere.
While Luda and Ism are busying themselves with the aforementioned provisions, I will get started on other resources that R3 didn't have. So who knows what you'll be seeing; hopefully perfected features from R3 and a simple collisions system.
Also, it seems likely that given just a little more time, we can have the collision system hooked up and iterating. Luda has rotated rectangles basically good to go; he can develop the rest of the system during the test phase, but the framework would be nice to have laid out.
As for the aforementioned Linux progress, we can't actually compile it on Linux at present due to some case labels skipping initializations, which Windows didn't even notice for some reason...
I'm quite tired. A lot of work went into the engine just today, but there's no sweeter payoff than seeing the system working again. It's a beautiful sort of thing.
I imagine everyone will understand the decision to prolong the release again; one of my bigger fears is immediate mediocrity. (Did I mention the syntax check button once again doesn't do anything?
It spent most of R3 like that... I won't let it for R4).This doesn't change the amazingly close proximity of the test. Besides, I had to squeeze anaphase in here somewhere.
While Luda and Ism are busying themselves with the aforementioned provisions, I will get started on other resources that R3 didn't have. So who knows what you'll be seeing; hopefully perfected features from R3 and a simple collisions system.