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 »
1456
Announcements / Re: Happenings
« on: January 28, 2011, 08:15:02 am »
Yeah, I still need to run that, but I'm afraid it'll gripe that it's not privileged. I'll add that now.
1457
Proposals / Re: mask_index
« on: January 28, 2011, 12:54:53 am »
I only bothered to set it when Colligma was hooked up. It wouldn't have gone unnoticed for long if it was needed. And hell, Ism's capable of adding it, now. She's done so in the past.
1458
Function Peer Review / Re: move_towards_point
« on: January 28, 2011, 12:54:16 am »
with (obj) direction=dir, speed=spd; isn't worth porting, considering the corresponding C++ is completely different.
1459
Proposals / Re: Static object variables
« on: January 28, 2011, 12:52:43 am »
As it stands, ENIGMA uses . for all other access. A single dot will represent the correct choice of GM access (integer.variable), instance access (inst.member), or pointer access ((&inst)->member). I was considering having it resolve scopes as well, but it may require a special flag on results from the type resolver or before the call to it, depending on how I have it structured (An actual 'int' keyword should be distinguishable from an int variable).
1460
Proposals / Re: Multiple Theads, are they a possibillity?
« on: January 28, 2011, 12:48:07 am »
What I was thinking about doing is adding threading by the same mechanism that I can add instance deactivation. Basically, I would keep a new tree and shit for each thread (deactivated instances get placed in thread -1, which is never processed).
Threading an object would be as simple as saying instance_thread(inst,thread).
Users would be allowed to figure out for themselves that sometimes life isn't as easy as putting everything in its own thread and hoping depth and shit stay in order.
Threading an object would be as simple as saying instance_thread(inst,thread).
Users would be allowed to figure out for themselves that sometimes life isn't as easy as putting everything in its own thread and hoping depth and shit stay in order.
1461
Proposals / Re: unable to parse (obj.variable) = value;
« on: January 28, 2011, 12:44:45 am »
I was under the impression the syntax was strictly as follows:
If GM is suddenly allowing that sort of thing, I will remove all checks related to assignment operators. That will add compatibility with stream structures like cout, anyway.
Code: [Select]
(obj).variable = value;
If GM is suddenly allowing that sort of thing, I will remove all checks related to assignment operators. That will add compatibility with stream structures like cout, anyway.
1462
Function Peer Review / Re: move_contact functions optimised for bbox
« on: January 28, 2011, 12:41:44 am »
Someone verify that and then bug me or Ism about it.
1463
Proposals / Re: do-until
« on: January 28, 2011, 12:41:01 am »
It should work.
#define until(x...) while(!(x)) is all I do.
I'll look into it all the same.
Edit: I don't see where you got that it doesn't work. If it gets past the syntax check (which it does) there's no reason for it not to work.
#define until(x...) while(!(x)) is all I do.
I'll look into it all the same.
Edit: I don't see where you got that it doesn't work. If it gets past the syntax check (which it does) there's no reason for it not to work.
1464
Off-Topic / Re: Automatic code formatting
« on: January 28, 2011, 12:36:15 am »
Select the code formatter from the Plugins menu.
1465
Proposals / Re: Div operator on script return value
« on: January 28, 2011, 12:35:15 am »
I've been thinking how I wanted to deal with DIV, and I guess the best option is just to cast both sides, which is messy.
1466
Announcements / Re: Happenings
« on: January 28, 2011, 12:27:04 am »
I'm not sure, Brett. Can you paste Compilers/Windows/gcc.ey? And the whole terminal output, that'd help. I need to know where Make is getting the mingw-g++.exe idea from. It should be able to find it, though, anyway... hmm...
1467
Function Peer Review / Re: move_towards_point
« on: January 25, 2011, 08:41:43 am »
A motion_set that's five lines in GML isn't really worth porting. Those kinds of functions are more like blueprints or suggestions than code. It doesn't help me if you just take advantage of ENIGMA's scoping system to do things that are a pain in the ass in plain, general C++.
Though, with the new instance system, they're now much easier to produce.
Though, with the new instance system, they're now much easier to produce.
1468
Proposals / Re: Uninitialised variables
« on: January 25, 2011, 08:37:43 am »
Yes. I'm still deliberating on how to store object files for multiple settings. You're probably enjoying a two second compile time, yes? That will go up in smoke every time you switch to a GMK with different settings if I don't do something to store objects for each configuration.
It's definitely going to involve some Make and YAML hackery.
I guess, instead, I could do my best to keep setting-dependent code in separate functions or variables in a single source, then have the systems use those.... We'll see. This method would be less efficient, but it shouldn't be that noticeable, and when you went to compile the final product, we could pass the settings in as macros to the sources in question. Thus, we'd have something like this:
It's definitely going to involve some Make and YAML hackery.
I guess, instead, I could do my best to keep setting-dependent code in separate functions or variables in a single source, then have the systems use those.... We'll see. This method would be less efficient, but it shouldn't be that noticeable, and when you went to compile the final product, we could pass the settings in as macros to the sources in question. Thus, we'd have something like this:
Code: (C++) [Select]
// For erroring on undefined vars
struct var
{
...
#if !defined OPT_UNIV_ERROR_UNDEFINED || OPT_UNIV_ERROR_UNDEFINED
bool initialized;
#endif
...
variant &operator* ()
...
#if !defined OPT_UNIV_ERROR_UNDEFINED || OPT_UNIV_ERROR_UNDEFINED
if (!initialized) show_error("Variable not defined"); // I'll probably use some C++ trickery to resolve the name
#endif
...
var():
#if !defined OPT_UNIV_ERROR_UNDEFINED || OPT_UNIV_ERROR_UNDEFINED
initialized(false),
#endif
...
// It will be the responsibility of IsmAvatar to ensure !(!OPT_UNIV_SHOW_ERRORS && OPT_UNIV_ERROR_UNDEFINED)
// But I'll probably double check it and not error
void show_error(...)
{
#if !defined OPT_UNIV_SHOW_ERRORS || OPT_UNIV_SHOW_ERRORS
#if !defined OPT_UNIV_ERROR_FATAL || !OPT_UNIV_ERROR_FATAL
if (MessageBox(enigma::hWnd, ...) == ID_ABORT)
exit(0);
#else
MessageBox(enigma::hWnd, ...);
exit(0);
#endif
#endif
}
1469
Ideas and Design / Re: Extension API
« on: January 24, 2011, 09:33:31 pm »
Making it easy for users to distribute compiled extensions on a per-platform basis is easily in our power and will probably be implemented. It will not be compatible with GM. It's also not relevant to this topic. This thread is basically dead; I'm considering closing it in favor of the other topic, but I'm generally opposed to closing things, so.
1470
Ideas and Design / Re: Rooms versus Panes (formerly Windows)
« on: January 24, 2011, 09:31:26 pm »
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 »