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 »
2056
Proposals / Re: Tierable Systems
« on: May 06, 2010, 04:44:38 pm »
"If they simply wanted to make a quick text editor do they really need the graphics library? Or the collision? Audio?
Thought not, you need to look at the benefits of a component based framework rather than your own miss-guided attempts at optimization."
I'm thinking I didn't come across clear enough. The difference between the tiering and component system is in two places.
1) The tier system doesn't require me to parse in accessors nor tax the CPU To lookup, store, push, and jump to that accessor.
2) If you remove the Graphics Tier, the Collision Tier goes with it; that's the only problem. It is very easily removed, and doesn't leave residue, unlike a component system.
So, the only drawback of mine is that you can't have collisions without graphics. I don't even see that as a problem.
And another thing, there is no audio tier. Nor audio component, if I'd used that system. Sounds in Game Maker don't use local variables, and so don't need a tier.
Rusky's component idea makes tiers entirely removable independent of one another, but uses slightly more memory and CPU time. Hardly a loss, but hardly a gain. Especially since if I thought I could have a collision tier that didn't access members of the graphics tier (such as image_index and image_angle), I wouldn't have placed it below that tier.
Further, this will not increase compile times except when you go from compiling a game that does away with a tier to compiling one that does not do away with a tier. In fact, even in that case, I can probably just leave all tiers in until Release compile.
No alignment is hard-coded; it is just calculated based on the size of each inherited tier. If youY want to edit a lower tier, a recompile is necessary. However, what I didn't realize when I originally posted this is that the system attached to each tier is basically intertwined with each higher tier. Adding to tiers is difficult, yes, but there's no point, I realize, unless you are extending the list of available functions, in which case the user will have to recompile it anyway. There's essentially no point to using any other system; rest assured, your fears are invein VAIN. VAIN. YOUR FEARS ARE IN VAIN.
Thought not, you need to look at the benefits of a component based framework rather than your own miss-guided attempts at optimization."
I'm thinking I didn't come across clear enough. The difference between the tiering and component system is in two places.
1) The tier system doesn't require me to parse in accessors nor tax the CPU To lookup, store, push, and jump to that accessor.
2) If you remove the Graphics Tier, the Collision Tier goes with it; that's the only problem. It is very easily removed, and doesn't leave residue, unlike a component system.
So, the only drawback of mine is that you can't have collisions without graphics. I don't even see that as a problem.
And another thing, there is no audio tier. Nor audio component, if I'd used that system. Sounds in Game Maker don't use local variables, and so don't need a tier.
Rusky's component idea makes tiers entirely removable independent of one another, but uses slightly more memory and CPU time. Hardly a loss, but hardly a gain. Especially since if I thought I could have a collision tier that didn't access members of the graphics tier (such as image_index and image_angle), I wouldn't have placed it below that tier.
Further, this will not increase compile times except when you go from compiling a game that does away with a tier to compiling one that does not do away with a tier. In fact, even in that case, I can probably just leave all tiers in until Release compile.
No alignment is hard-coded; it is just calculated based on the size of each inherited tier. If youY want to edit a lower tier, a recompile is necessary. However, what I didn't realize when I originally posted this is that the system attached to each tier is basically intertwined with each higher tier. Adding to tiers is difficult, yes, but there's no point, I realize, unless you are extending the list of available functions, in which case the user will have to recompile it anyway. There's essentially no point to using any other system; rest assured, your fears are in
2057
Issues Help Desk / Re: #define?
« on: May 05, 2010, 08:20:02 pm »
Right now, you can't, as I broke Whitespace. :3
In the near future, you will just go to Enigma Settings and click Definitions, then add them there.
In the near future, you will just go to Enigma Settings and click Definitions, then add them there.
2058
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.
2059
Proposals / Re: Custom Widgets
« on: May 05, 2010, 07:25:38 pm »
What does that mean for my request?
2060
Proposals / Re: On Settings and Dependencies
« on: May 05, 2010, 07:21:11 pm »
Haha, indeed. I forgot I did not, after I spent the effort implementing them. In fact, I guess they are untested except defaults.
2062
Proposals / Re: On Settings and Dependencies
« on: May 05, 2010, 12:17:59 pm »
Good, then consider it a plan. Can you have it in a scroll field with expandable groups by file, if we have too many options? Or perhaps in different tabs?
2063
Proposals / Re: Custom Widgets
« on: May 05, 2010, 12:13:04 pm »
Ism: I mean, can you create a bitmap containing a rendered font glyph? GM stores an array of bitmaps for each glyph. Fortunately, they are monochrome, and maybe monotone. I'm not sure how many colors they actually require; score_under, do you know? Also, I don't want platforms hardcoded in one file.
2064
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...
2065
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 false
And 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...
2066
Announcements / Re: Finals
« on: May 04, 2010, 09:05:33 pm »
As usual I'm feeling slightly more religious after today's turn of events.
I'm glad Ism fixed that problem.
Tomorrow holds calculus.
Thursday holds the worst test of all... Political science... God have mercy on my soul, &c.
I'm glad Ism fixed that problem.
Tomorrow holds calculus.
Thursday holds the worst test of all... Political science... God have mercy on my soul, &c.
2067
Announcements / Re: Finals
« on: May 04, 2010, 09:26:02 am »
11th:
Hah, no one ever tells me anything. But yes, I won't be doing that. I'm about to proof the paper with my partner and possibly rehearse something.
Ism:
I never explicitly told you to do so, as the thought never occurred to me until its anti-consequences made me want to rip out my hair. Rev 203 should work for people who do not need to include stdio explicitly to use it. If not, then yes, wait or revert. Or add #include <stdio.h> and if that doesn't fix it, I give up for now.
I hopped buildings, but am still far from home...
Hah, no one ever tells me anything. But yes, I won't be doing that. I'm about to proof the paper with my partner and possibly rehearse something.
Ism:
I never explicitly told you to do so, as the thought never occurred to me until its anti-consequences made me want to rip out my hair. Rev 203 should work for people who do not need to include stdio explicitly to use it. If not, then yes, wait or revert. Or add #include <stdio.h> and if that doesn't fix it, I give up for now.
I hopped buildings, but am still far from home...
2068
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.
2070
Issues Help Desk / Re: STUPID IRC
« on: April 26, 2010, 10:25:30 pm »
This the fuck.
The usual.
Why not?
All I did was ban and kick you after you said the forums were dying and you left.
I did as soon as you were done being banned and kicked.
Nah.
Nah.
Yeaaaaaaaaaaaaaaaaaaaaaaaaaaaaah.
The usual.
Why not?
All I did was ban and kick you after you said the forums were dying and you left.
I did as soon as you were done being banned and kicked.
Nah.
Nah.
Yeaaaaaaaaaaaaaaaaaaaaaaaaaaaaah.
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 »