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:
list a; var b = 10;
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.
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
, 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
). 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:
int window = wgt_window_create(480, 96);
int layout = wgt_layout_create(window,
"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"));
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.