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 »
1621
Announcements / Re: Long enough without an update
« on: November 04, 2010, 11:57:56 am »
It will work for production level, but I've not yet committed it. I'm looking for the best way to tie it into the current system; it will probably be given its own directory called Widget_Libraries (X11 has none, so I can't just tie in widgets to the Platforms/ directory).
They'll be up before you know it.
They'll be up before you know it.
1622
Announcements / Long enough without an update
« on: November 04, 2010, 09:42:40 am »
As usual, we've been trying to get all our ducks in a row. It looks something like this:
More specifically, it looks like this:
(Or more recently, this: http://dl.dropbox.com/u/1052740/enigma/screens/fonts/Screenshot-Untitled%20Window-2.png)
And with that, here's what's been happening.
Resources
ENIGMA has gained two new resources lately, namely backgrounds (courtesy of HaRRiKiRi and TGMG) and fonts (my own doing). However, fonts must be added via font_add_sprite(), and backgrounds must be drawn manually. Ism is working on giving me a compression method, which I will use to re-zlib the font glyphs after I pack them. Also, before I ever got to post news on fonts, HaRRi added all the font functions (they still need finalized once it is convenient to test them; it's nothing more than 20 minutes of work, if only the issue I have foreseen now afflicts them). Maybe I'll do something about backgrounds soon...
To tie up a couple questions, by "pack them (the glyphs)," I mean stick them tightly together to conserve VRAM and increase the likelihood that they'll work on, say, the iPhone. I wrote a rectangle packing algorithm, which in the outdated screenshot above is packing the font glyphs a little too tightly. That has since been fixed, but what you see is the packed result of what was once a 256*256 font sheet.
Systems
As pictured vaguely above, r9k has been working on triangle-based collisions. These will evolve into polygon-based collisions with a little TLC. Thanks to some other changes mentioned later in this post, r9k was able to get simple triangle-triangle collision class, Triangle, working from within EDL.
Code
I fixed a few problems with the syntax checker and parser, and here's what they can do now:
If that doesn't mean anything to you, just know that it puts a lot of power at the finger tips of those to whom it does. Since then, r9k found a problem seemingly regarding the difference between class and struct in my parser. I'll be looking into that shortly enough.
Technical details:
When resolving operator., ENIGMA isolates the left-hand side of the dot, and runs it through a stack-based coercer, which resolves a viable type to represent the expression. Any variables in the expression will be searched for starting from the script scope, then to the globalvar scope, then the object scope, and finally to the global scope. If no type is explicitly named or no variable is found, the coercer defaults to var. From there, the type is checked for a member by name of the right-hand side of the dot.
If one is found: The type is checked for any reference marks (such as * or []) that would indicate it's a pointer. If one's found, the dot becomes ->. Otherwise it's left alone.
If one is not found: The expression is placed in parentheses. If the right-hand side is a global local (a local found in all instances), the entire segment is rewritten as enigma::glaccess(expression)->varname, where glaccess() returns a pointer to the parent class containing all global locals. Otherwise, the expression is replaced with an accessor function, in this format enigma::varaccess_varname(expression). The compiler will later generate an accessor function to fit the bill. Additionally, the expression is cast to int to reduce the likelihood for compile error/warn.
Additionally, I finished with(), in the sense that "other" now works in it.
Finally, just yesterday I implemented all the mouse events. Most still need tested; they are bbox based for now.
Portability/Extensibility
Ism now uses my network of YAML files to provide build platform/API options to the user. So now, at least on Mac, you can select "iPhone" or "Android" to build for. I don't believe TGMG has capitalized on this yet (there is still work to do), but we should have the whole system working soon enough (implying the ability to switch between target OS/device from LGM).
Also, someone submitted a bug that ENIGMA wasn't working on Windows a while back; it's difficult to keep it working on both platforms. Today, I'm going to get mingw-get working with ENIGMA.exe, so we can finally have a respectable install process on Windows.
I'm also going to hit Ism up to call "make enigma" even when she thinks it doesn't need done.
Finally, I have been working on widgets for ENIGMA. The reason for this is so I can finally bring Build Mode to R4. Some of you may remember it from R3; It was by far the best idea introduced in the system. Widgets are looking like this so far:
Those functions will be available to the user and used by Build Mode's new system. Build Mode will be renamed to Design Mode to avoid ambiguity in communication.
Also, I did most of the GM dialogs (get_color, get_open_filename, show_menu, etc.). I also added, just to be original, my own show_menu_ext:
So anyone that was hoping for a powerful widget interface in ENIGMA can rest easy. However, to answer someone's next question, no, you cannot place the widgets over your game screen. You need to make them their own window. Someone will probably code an in-game widgeting library later on. (Menus and color selections are, of course, their own windows, and do not need any special treatment to make).
Anyway, as you can see, the new widget library has no trouble re-creating R3 Build Mode's UI.
Lastly finally, Ism has been working on some DND functions. With that, we needed to fix isolated, system-invoked events such as Create to maintain a valid self-referential iterator so functions like action_set_motion (or whatever the hell it is; no one uses those directly) can accurately access the current instance's locals. For the continued success of this endeavor, I will need to finish my YAML-based instance block system (very similar to Rusky's proposal of components from long ago, only without unsightly pointer members; feel free to irritate the issue and we can discuss the intricacies of why I won't tolerate pointer members and why the low-level components are still tiered ).
And on the subject of events, in fixing up the mouse wheel event, I added mouse_get_wheel_vangle(). It returns how many increments the mouse wheel has rolled vertically, even though most devices anymore do not have a wheel but a trackpad of sorts (Laptops, Apple Magic Mouse). Also, I've seen only two devices with a horizontal scroll wheel (Apple's Mighty Mouse scroll ball, some off-brand fucking-huge mouse with 36 buttons on each surface). That being the case, feel free to propose a better name.
Cheers.
More specifically, it looks like this:
(Or more recently, this: http://dl.dropbox.com/u/1052740/enigma/screens/fonts/Screenshot-Untitled%20Window-2.png)
And with that, here's what's been happening.
Resources
ENIGMA has gained two new resources lately, namely backgrounds (courtesy of HaRRiKiRi and TGMG) and fonts (my own doing). However, fonts must be added via font_add_sprite(), and backgrounds must be drawn manually. Ism is working on giving me a compression method, which I will use to re-zlib the font glyphs after I pack them. Also, before I ever got to post news on fonts, HaRRi added all the font functions (they still need finalized once it is convenient to test them; it's nothing more than 20 minutes of work, if only the issue I have foreseen now afflicts them). Maybe I'll do something about backgrounds soon...
To tie up a couple questions, by "pack them (the glyphs)," I mean stick them tightly together to conserve VRAM and increase the likelihood that they'll work on, say, the iPhone. I wrote a rectangle packing algorithm, which in the outdated screenshot above is packing the font glyphs a little too tightly. That has since been fixed, but what you see is the packed result of what was once a 256*256 font sheet.
Systems
As pictured vaguely above, r9k has been working on triangle-based collisions. These will evolve into polygon-based collisions with a little TLC. Thanks to some other changes mentioned later in this post, r9k was able to get simple triangle-triangle collision class, Triangle, working from within EDL.
Code
I fixed a few problems with the syntax checker and parser, and here's what they can do now:
Code: (EDL) [Select]
list a; var b = 10;
a.push_back(b);
show_message(string(a.size()));
rect* a = some_rect_function();
a.left = 0;
If that doesn't mean anything to you, just know that it puts a lot of power at the finger tips of those to whom it does. Since then, r9k found a problem seemingly regarding the difference between class and struct in my parser. I'll be looking into that shortly enough.
Technical details:
When resolving operator., ENIGMA isolates the left-hand side of the dot, and runs it through a stack-based coercer, which resolves a viable type to represent the expression. Any variables in the expression will be searched for starting from the script scope, then to the globalvar scope, then the object scope, and finally to the global scope. If no type is explicitly named or no variable is found, the coercer defaults to var. From there, the type is checked for a member by name of the right-hand side of the dot.
If one is found: The type is checked for any reference marks (such as * or []) that would indicate it's a pointer. If one's found, the dot becomes ->. Otherwise it's left alone.
If one is not found: The expression is placed in parentheses. If the right-hand side is a global local (a local found in all instances), the entire segment is rewritten as enigma::glaccess(expression)->varname, where glaccess() returns a pointer to the parent class containing all global locals. Otherwise, the expression is replaced with an accessor function, in this format enigma::varaccess_varname(expression). The compiler will later generate an accessor function to fit the bill. Additionally, the expression is cast to int to reduce the likelihood for compile error/warn.
Additionally, I finished with(), in the sense that "other" now works in it.
Finally, just yesterday I implemented all the mouse events. Most still need tested; they are bbox based for now.
Portability/Extensibility
Ism now uses my network of YAML files to provide build platform/API options to the user. So now, at least on Mac, you can select "iPhone" or "Android" to build for. I don't believe TGMG has capitalized on this yet (there is still work to do), but we should have the whole system working soon enough (implying the ability to switch between target OS/device from LGM).
Also, someone submitted a bug that ENIGMA wasn't working on Windows a while back; it's difficult to keep it working on both platforms. Today, I'm going to get mingw-get working with ENIGMA.exe, so we can finally have a respectable install process on Windows.
I'm also going to hit Ism up to call "make enigma" even when she thinks it doesn't need done.
Finally, I have been working on widgets for ENIGMA. The reason for this is so I can finally bring Build Mode to R4. Some of you may remember it from R3; It was by far the best idea introduced in the system. Widgets are looking like this so far:
Code: (EDL) [Select]
int window = wgt_window_create(480, 96);
int layout = wgt_layout_create(window,
"OOOOOOO\n"
"PUXYWHS\n"
"FRGGIIS", 2, 2);
int cbbobj, bpause, bfreeze, bundo, bredo, bstop, tegx, tegy, tegw, tegh, cbgrid, cbiso;
wgt_layout_insert_widget(layout, "O", cbbobj = wgt_combobox_create("object0|object1|object2|cat|hat|box|wall|toilet|cloud|mushroom"));
wgt_layout_insert_widget(layout, "P", bpause = wgt_button_create("Pause"));
wgt_layout_insert_widget(layout, "F", bfreeze = wgt_button_create("Freeze"));
wgt_layout_insert_widget(layout, "U", bundo = wgt_button_create("Undo"));
wgt_layout_insert_widget(layout, "R", bredo = wgt_button_create("Redo"));
wgt_layout_insert_widget(layout, "X", tegx = wgt_textline_create("X",3));
wgt_layout_insert_widget(layout, "Y", tegy = wgt_textline_create("Y",3));
wgt_layout_insert_widget(layout, "W", tegw = wgt_textline_create("W",3));
wgt_layout_insert_widget(layout, "H", tegh = wgt_textline_create("H",3));
wgt_layout_insert_widget(layout, "G", cbgrid = wgt_checkbox_create("Grid"));
wgt_layout_insert_widget(layout, "I", cbiso = wgt_checkbox_create("Iso"));
wgt_layout_insert_widget(layout, "S", bstop = wgt_button_create("Stop"));
wgt_window_show(window);
Those functions will be available to the user and used by Build Mode's new system. Build Mode will be renamed to Design Mode to avoid ambiguity in communication.
Also, I did most of the GM dialogs (get_color, get_open_filename, show_menu, etc.). I also added, just to be original, my own show_menu_ext:
Code: (EDL) [Select]
show_menu_ext(32,32,"test|of|menus|-|>Project|/Save|Close|<|[]Checkbox|[*]Checked|-|()Radio|(*)Radiod|etc")
So anyone that was hoping for a powerful widget interface in ENIGMA can rest easy. However, to answer someone's next question, no, you cannot place the widgets over your game screen. You need to make them their own window. Someone will probably code an in-game widgeting library later on. (Menus and color selections are, of course, their own windows, and do not need any special treatment to make).
Anyway, as you can see, the new widget library has no trouble re-creating R3 Build Mode's UI.
Lastly finally, Ism has been working on some DND functions. With that, we needed to fix isolated, system-invoked events such as Create to maintain a valid self-referential iterator so functions like action_set_motion (or whatever the hell it is; no one uses those directly) can accurately access the current instance's locals. For the continued success of this endeavor, I will need to finish my YAML-based instance block system (very similar to Rusky's proposal of components from long ago, only without unsightly pointer members; feel free to irritate the issue and we can discuss the intricacies of why I won't tolerate pointer members and why the low-level components are still tiered ).
And on the subject of events, in fixing up the mouse wheel event, I added mouse_get_wheel_vangle(). It returns how many increments the mouse wheel has rolled vertically, even though most devices anymore do not have a wheel but a trackpad of sorts (Laptops, Apple Magic Mouse). Also, I've seen only two devices with a horizontal scroll wheel (Apple's Mighty Mouse scroll ball, some off-brand fucking-huge mouse with 36 buttons on each surface). That being the case, feel free to propose a better name.
Cheers.
1623
Off-Topic / Re: Does the tracker need severity?
« on: November 04, 2010, 07:55:43 am »
I just wanted to be able to edit the severity rating myself. I never intended for the user to even have a say in it, but it came out that the user is the only person that ever has a say in it, but I figured it'd work until you added an edit capability.
I'm not actually interested in a hidden priority list, but if you think it'd help others who would use Spray, by all means, add it.
I'm not actually interested in a hidden priority list, but if you think it'd help others who would use Spray, by all means, add it.
1624
General ENIGMA / Re: DnD Functions
« on: November 04, 2010, 12:09:35 am »
It is, I just wasn't paying much attention to the thread.
1625
Function Peer Review / Re: action_move
« on: November 04, 2010, 12:06:06 am »
I don't know off the top of my head the implications of taking const char[9] as a parameter; I am relatively certain that's the same as just const char*. Whatever the actual case, you really wanted const char[10] for the NULL at the end of the literal.
My other beef is that, despite this being a function instead of a macro, it does not take advantage of non-EDL optimizations; namely setting direction.dval and speed.dval manually, then manipulating hspeed.dval and vspeed.dval manually.
I'm actually too tired and lazy right now to do the trivial amount of text insertion required to put that to code. >.<
-sigh-
Assuming all the rest of your code is right, and that I'm remembering the name of my own class member correctly.
My other beef is that, despite this being a function instead of a macro, it does not take advantage of non-EDL optimizations; namely setting direction.dval and speed.dval manually, then manipulating hspeed.dval and vspeed.dval manually.
I'm actually too tired and lazy right now to do the trivial amount of text insertion required to put that to code. >.<
-sigh-
Code: (C++) [Select]
const double dir = ((enigma::object_planar*)enigma::instance_event_iterator->inst)->direction.dval = chosendirs[choices];
((enigma::object_planar*)enigma::instance_event_iterator->inst)->speed.dval = chosendirs[choices] == -1 ? 0 : argspeed;
hspeed.dval = speed.dval * cos(dir), vspeed.dval = speed.dval * sin(dir);
Assuming all the rest of your code is right, and that I'm remembering the name of my own class member correctly.
1626
Proposals / Re: Thoughts on forum registration...
« on: November 03, 2010, 11:55:14 pm »
Actually, bots kept getting past the first question, which indicated to me that they're either smart enough to segment the domain name based on its - location, or they had enough time to guess any relevant keyword turned up by Google (or available on that page). Really, it seems more likely to me that a paid hand got through it by being smart enough to read the logo atop the page (which seems ridiculously unlikely considering ENIGMA's small pagerank: how can any human have just happened upon this site?). The filter was designed to stop not only bots, but uninterested humans.
GM's language, its tileset pseudonym, and ENIGMA's own language were all acceptable answers. Needless to say, we haven't had any bots since. (In fact, we've had two new users, yourself included, and neither has said anything about sterling silver or real estate).
I'm going to give this a week, and if no bots join, I'll try it with just yellow fruit, for which there are a bazillion acceptable answers.
GM's language, its tileset pseudonym, and ENIGMA's own language were all acceptable answers. Needless to say, we haven't had any bots since. (In fact, we've had two new users, yourself included, and neither has said anything about sterling silver or real estate).
I'm going to give this a week, and if no bots join, I'll try it with just yellow fruit, for which there are a bazillion acceptable answers.
1627
Tips, Tutorials, Examples / Re: Chesee finder - pathfinding and collision engine
« on: November 02, 2010, 06:02:04 pm »
Some things use bboxes, sure; it would be horrible to have collision tests done on every face of every landform and every character. But to treat each object as a simple box isn't always a great idea. Often a simplified mesh is used for collisions instead of just a box. The meshes are, of course, composed of triangles.
A good game, though, will use more than just meshes and boxes, anyway. Since most games are not designed to use the kind of general-purpose collision functions Game Maker offers (namely, place_free(): the number one most whored function in GM), each "object" will be treated uniquely by the controller (possibly the player). I intend to offer a number of functions for resolving primitive and mesh distances. More variety = more efficiency.
A good game, though, will use more than just meshes and boxes, anyway. Since most games are not designed to use the kind of general-purpose collision functions Game Maker offers (namely, place_free(): the number one most whored function in GM), each "object" will be treated uniquely by the controller (possibly the player). I intend to offer a number of functions for resolving primitive and mesh distances. More variety = more efficiency.
1628
Tips, Tutorials, Examples / Re: Chesee finder - pathfinding and collision engine
« on: November 02, 2010, 12:47:35 pm »
r9k's triangles are rotated. As far as 3D detection goes, I don't intend to use bboxes for 3D; I'll be skipping right to polygon meshes.
1629
General ENIGMA / Re: DnD Functions
« on: November 02, 2010, 12:41:34 pm »
Ideally. At this point, options are still a YAML clusterfuck. But after we have it so you're able to switch out APIs, I don't see why not.
1630
General ENIGMA / Re: DnD Functions
« on: November 02, 2010, 12:34:26 pm »
variant::operator bool() { return dval > .5; }
1632
Tips, Tutorials, Examples / Re: Chesee finder - pathfinding and collision engine
« on: November 02, 2010, 09:17:38 am »
I have something that checks bboxes in ENIGMA, yes. Non-rotated. It's just called collision_bbox_rext(); it's like a less accurate place_free.
Also, r9k's been working on triangle/polygon collisions. Those'll be done sometime in the not-so-distant future.
Also, r9k's been working on triangle/polygon collisions. Those'll be done sometime in the not-so-distant future.
1633
General ENIGMA / Re: DnD Functions
« on: November 02, 2010, 12:31:06 am »
If it's not the case that action_if is a substitute for "if", then it should be defined as inline bool action_if(double x) { return x >= .5; } (bool(x != 0) is redundant, anyway).
1634
General ENIGMA / Re: DnD Functions
« on: November 01, 2010, 08:20:16 pm »
...
LGM should handle action_if itself, without writing action_if.
I am unsure of the function of action_if in a GML script. Can someone verify it?
LGM should handle action_if itself, without writing action_if.
I am unsure of the function of action_if in a GML script. Can someone verify it?
1635
Function Peer Review / Re: GML: All draw_text functions +(string_width, _height, _width_ext, _height_ext)
« on: November 01, 2010, 07:52:02 am »
Mmmyes. Wonder which one the code uses.
Can't test/fix now; off to class.
Worst case scenario: It's broken and we have to add svx*g-> to each xx and cvx * g->y to each yy...
Can't test/fix now; off to class.
Worst case scenario: It's broken and we have to add svx*g-> to each xx and cvx * g->y to each yy...
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 »